XMLHttpRequest advantage over IFrame

There is one advantage XMLHttpRequest has over IFrame, and that is multiple objects. Lets say you want to submit miltiple updates, each update triggered by user clicking on a checkbox, if you are XMLHttpRequest you can create an instance for each request,If you are using one iframe then you need to wait for each request to finish before submitting the next. I guess you can do the same with IFrame, but some how it seems (to me) more natural to use multiple instances of XMLHttpRequest than multiple instances of IFrame.

There're several ways to send multiple requests.
Instead of use multiple XmlHttpRequests, you can create multiple IFrames and send one request at each one or also you can execute more than one action in only one IFrame call.
You can also use another AJAX based technologies, like Image request or even Script request. There're also a Cookie request that appear recently.

No matter how you send your request, in all of them you have possibilities to send more than one per time. =)


Cheers,

Nothing stops you from having multiple IFrame objects to send multiple requests, in parallel if you really need them.

i just get the very intressting AJAX over IFRAME Mailing.
It now 3 Years ago i wrote my Intranet-Applications with this technic.
It's a good workaround to interact with a Server without reloading the Page.
I also checked out some AJAX solutions with PHP.
And your'e right. Some of them are incredible slow.
Your'e also right that not all Browser supports HTTP requests.
But .. sorry .. actuall Browsers can and they are all for free.
And your'e really right if you say IE uses a unsecure Active X component.
But that's a problem from Microsofts Concept. Normally all other
browsers have an real secure JS envirnonment. (like Firefox etc.)
The next is, how AJAX is used by the most Programmers.
The Server gives XML back and this XML is parsed by the Client via DOM.
It's realy strange. It seems XMLer's only know XML and only XML ...
But XML is realy complicatet to read and write if you compare it to other technics.
Double work for one Job. That's the reason why AJAX is often so poorly
slow (very slow in IE ...).
So my solution is a combination of both.
HTTP-Reqest receive clean HTML from the Server and i place it into the
Element i want to via .innerHTML.
Easy, clean and realy quick.
Server sided mostly i use PHP+Smarty for rendering (Smarty is a genious Lib!) .
For JS-Routines i now use the prototype Lib (wich is also used by RUBY on Rails and some extended JS-Libs like RICO script.acul.us eg,), wich can be easily extended if you want.
Try it .. it 's realy fun to programm. The most actual Browsers can handle it very well.
For Form-Submitting normally i use the I-Frame as target and receive
a script Element back to commit Status-Messages or do some post-workins.

If we can have a good protocol for transmit Form Data and receive
both, HTML and JS-Instructions it will be really helpfully.

Hope i could give you a new idea.

As I mentioned in the blog post, I have developed a plug-in for my forms generation and validation class that uses an IFrame to submit a from via AJAX. It can be used to submit AJAX requests in contexts where there is no form, but this is the most common scenario.

The plug-in intercepts the AJAX request on server side as demonstrated by the test_ajax_form.php example script.

The plug-in posts event messages to a queue of the form class. Applications should watch that queue to check if the script is being executed as part of an AJAX request.

Applications should respond to those event messages to tell the plug-in what to do. The applications may instruct the plug-in to send an AJAX response that defines one or more actions to be executed on the browser side, such as updating parts of the browser page, redirecting to a new page, etc..

The plug-in generates the necessary JavaScript code to execute such response actions. The good part is that you do not need to know any JavaScript to define the AJAX response actions, but you can tell the plug-in to execute arbitrary JavaScript too.

Another good thing is that you can tell the plug-in to send part of the response immediately without finishing the HTTP connection, then you execute some possibly lengthy action, give some progress feedback, and when you are done, send some finish success feedback, probably redirecting to a new page after a pause.

This certainly makes the sites more usable letting the user know what is going on in all stages.