Blog Post

by Simon Willison

This post has 15 responses so far

1. Bah – just look at the code. No DOCTYPE, pure TABLE design. *sigh*

   Adagio
   September 20th, 2004 at 2:35 am

2. I don’t think we’ve even begun to scratch the surface of the possibilities that remote scripting opens up.

   Second that!

   HarryF
   September 20th, 2004 at 2:45 am

3. Once the iframe document has finished loading, it calls a function to copy its own innerHTML in to a div contained in the parent window that loaded it.

   I know that for my application I do something similair. What I generally do, is when the iframe loads, call a function on the main javascript window. This window can then access the data from the iframe that has now loaded.

   Part of the reason for doing this is I have a sort of switch back. I use the iframe for automatic checking, e.g. lets say checking for new emails to arrive so it reloads itself. When some remote server call is made, i reuse the iframe to call that page, and then reset it to the auto reload of the email check page, so far it works pretty well; I have functionalised it and linked into my html/content functions.

   I don’t have demo online but will currently; I have begun to realise how useful this is going to be for our app, unfortunatly that was a bit late in development stage so it is going to have to be next version to start fully using it, but the usefulness is so there.

   One major thing I have been considering is pre-form submit validation. You can now remove all that js validation; validate using the PHP you will do the validation with anyway and save the rewrite of validation code in two languages.

   padders
   September 20th, 2004 at 4:10 am

4. On that validation, I am wondering if you can:

   i) Someone enters form data. Press the Submit button
   ii) Make a remote script call to server
   iii) If not validated, some javascript wizadry to explain this to user. Page is already there etc.
   iv) If validated, perhaps do whatever we where going to do, then send back a call to the browser to redirect to the page you where going to anyway.

   Advantages:

   i) no js validation functions
   ii) no need to even consider writing the PHP to handle creating forms to handle a failed form submit, e.g. handling difference between editing a form and redoing a form etc.
   iii) Much quicker, no browser reload for a failed form submit.

   Cearly, this would completly break the app if you disable javascript, but in apps where you have some control over the environment, that should not be a problem.

   padders
   September 20th, 2004 at 4:16 am

5. padders: I love the idea of validation against your server-side PHP logic using remote scripting. I’ve implemented dual validation (client- and server-side) several times and the duplication of validation logic in two different languages has always bugged me.

   Skunk
   September 20th, 2004 at 4:51 am

6. Tooting my own horn though it may be, this is sort of what I was trying to get at in http://www.sitepoint.com/article/practical-xml-form-validation

   For full-strength validation, the technique would need to be taken further, but there’s no reason you can’t specify your validation in one xml document residing on your server, and have both your javascript and server side language reference that file to validate forms.

   illuminosity
   September 21st, 2004 at 9:37 am

7. Gmail seems to be doing something similar, though their code is quite obfuscated.

   The question I have is, does this scripted switching of content sit well with screen readers? Do they somehow get notified of the change?

   MH
   September 21st, 2004 at 9:49 am

8. I doubt screen readers cope very well with remote scripting – it relies on JavaScript support for one thing, and I doubt that the hooks for understanding that new content has been loaded are particularly useful even in screen readers that have JavaScript support. Creating accessible tools with remote scripting is definitely an interesting challenge, as it requires a “fall back” mode for non-JavaScript browsers.

   Skunk
   September 21st, 2004 at 8:41 pm

9. Surely posting an entire form back to the server for validation is giong to take just as long whether done via a hidden iFrame or with an old-fashioned POST/GET of the entire page. If all of the elements of the page have been cached by the browser where is the advantage (especially if you have to write in extra code to handle accessibility)?

   omnicity
   September 24th, 2004 at 10:12 am

10. omnicity,
    Posting the entire form isn’t really as huge a concept as it sounds, because all you’re sending is a bunch of string data. Then if we’re doing validation you can load the results into the page elements that display your message or reload the form fields etc…

    This is great. I’m more partial to the XML HTTP Request method becasue it seems a whole lot cleaner, but either way it’s so much better without a full page refresh.

    awasson
    September 29th, 2004 at 11:39 pm

11. Shouldn’t the hidden iframe trick work with opera? A9 does a page refresh instead when viewed from opera. Why?

    chili
    September 30th, 2004 at 12:47 am

12. awasson: You missed my point – either method sends the same amount of data to the server, give or take a few bytes, but where is the advantage in returning XML that the client must manipulate, compared to returning pre-formatted HTML? WE’ve all spent a lot of time seperating content from presentation recently, to good advantage, but this seems to be going backwards, by now intertwining content, presentation, code and an additional markup language.

    omnicity
    September 30th, 2004 at 5:39 am

13. all this things sums up to one thing. the guy who has the most time to develop and tweak his web application will definitely have the best user interface. users dont care in what way it was implemented. they only care if it’s usable or not.

    francis
    September 30th, 2004 at 7:12 am

14. The focus on form validation for this technique is an error. The point of javascript validation is to avoid the request and response lagtime of communicating to the server; remote scripting does not avoid this problem and is therefore not a solution to it.

    The true benefit of this technique is that you can refresh portions of a page without downloading the whole interface again. Remote scripting is useful during form submission only if the response does not affect the whole page — for example, a poll that displays the results once submitted, or a content management system that redisplays the content after having been saved in the database.

    One thing we use it for is we dynamically retrieve select-lists of names and addresses from the database as the first few letters are typed. The advantage here is that the select-list allows instant recognition as to whether the person has already been entered, and with peculiar spellings it reduces inaccurate entry.

    I can also see more complex applications that need fast response times being done on the web now. For example, a hotel reservation system could dynamically update the availability of rooms on a calendar based on user input of room type, date range, etc. Only after all the information is settled on would the actual submission take place; until then, only the relevant changes would shuttle back and forth between the client and server.

    Ben Curtis
    October 1st, 2004 at 1:22 pm

15. I’ve built something like this too, but then purely JS based…

    If you use the ‘target’ attribute of a hyperlink, and fill in the ID of any existing div on the page, the link will automagically be loaded into the div through a hidden iframe.

    http://verbouwing.schizofreend.nl/divloader.html
    It could be very easily expanded to catch form tags too, but i haven’t needed that yet so not implemented :P

    SchizoDuckie
    November 19th, 2004 at 3:52 am