I click a link in a browse() window, and instead of the whole window flashing / losing entered data / having the scroll reset, a custom javascript function is called (one that is already on the page, as in the /proc/Output() example) and textual data is passed to it as parameters. From there, in this specific example, I take two params (object ID and new innerText) and use those to update an element on the page without disrupting anything else or the document's scroll position.
client/New()
. = ..()
src << browse({"
<html>
<head>
<title>
test
</title>
<script type="text/javascript">
function ReplaceText(ID, NewText) {
alert("check");
document.getElementById(ID).innerText = NewText;
}
</script>
</head>
<body>
<p id="testelement">Testing...</p>
<a href="?a=test">test</a>
<input type="text" value="This doesn't get overwritten!"></input>
</body>
</html>"}, "window=wtest")
client/Topic(href,href_list[],hsrc)
var/list/T = list( )
T["ID"] = "testelement"
T["NewText"] += "IT WORKED"
usr << output(list2params(T),"wtest:ReplaceText")
In this case, "wtest:ReplaceText" resolves to the window created by browse() (and a specific function therein) and not a control in the interface. The idea behind this is to allow a sort of pseudo-AJAX in browse windows by having Dream Daemon "push" updates to the clients (in the form of javascript calls) instead of having the browse windows "pull" through the (unsupported anyways) XmlHTTPRequest object.
