Log in

No account? Create an account
Remote scripting - Nick [entries|archive|friends|userinfo]

[ website | gagravarr.org ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Remote scripting [Aug. 8th, 2003|09:18 am]
(If you don't know much about advanced web design, you can probably stop reading now)

Remote scripting is perhaps a little evil, but very cool. It's the process of having something inside you page go talk to a webserver, get back a respone, and do something with it, without reloading the page.

The most common use of it is for populating form fields as you go along, eg you pick option 5 in drop down box 1, and it goes off an gets the appropriate options for drop down box 2.

The magic for this is all managed through a new tag, <iframe>, or inner frame. You set the location of this frame to be a remote page, normally via javascript. The browser goes off, contacts the server, and puts the resulting page into the document, with the iframe as its parents root. You now have a baby DOM tree hanging off your main DOM tree, linked via an iframe node.

Finally, you register a callback with the browser. When the page has loaded, this is triggered. Quite what the script does with the contents of the new tree is up to it, but it generally depends on the combination of client and server side stuff

The most common free remote scripting set is written by Brent Ashley. It has a client side javascript source, which you call from your page, and will call you back with the results. It also has a large number of sample server side scripts, for getting the info and passing it back to the client.

The chosen method of data storage for the script suite is to create a document with a form in it, create a TEXTAREA tag inside the form, and pop the result text into the text area. The advantage of this method is that you can get the data back using FORM related calls in browsers without full DOM support.

Unfortunately, the current version of the script doesn't work with Opera 7. You get a javascript error of "Security Error: attempted to read protected variable". A bit of digging showed this to be because the script mis-detected Opera as IE, so was trying to do some evil IE specific way of setting the IFRAME's location, which Opera was having none of. With a quick bit of coding I was able to add correct detection for opera, and the appropriate document creation and location setting.

Then I hit the problem of getting the field value back out of the document. The methods used for IE and Mozilla were a little dodgy, using a mix of DOM and form access methods, rather than a more traditional "DOM, please get me the tag with this ID from this tree branch, then grab me the value of it". So, I altered the server side script to set an ID on the text area (it only had a name field before, how unhelpful was that?), and wrote the appropriate DOM magic. It now all works :-)

In proper open source style, you'll be glad to know I've sent off a patch to the author, and he said it should make it into the main distribution shortly. Most importantly though, the magic remote scripting stuff used in the site we're currently writing now works in Opera, which is always nice.