|I have an issue with the improper use of technical terms. In this case, using AJAX to mean dHTML (It's a bit like saying it's better to code JAVA using C, which makes about as much sense)|
On a functional level, I agree that the iFrame is a lot better than using AJAX, but not for the same reasons. Using an AJAX approach means the browser is kept in the dark about what is going on; the navigation is moved from the browser to a hidden in-page system. Consequently there is no history to traverse, no data transfer to be stopped, and no status indication of what is actually going on. It bypasses the browser entirely. This is a "Bad thing(tm)".
The question then becomes, does your iFrame solution bypass the browser. If not, your solution is excellent. If it does, rethink your solution - you don't want to have your users wondering what kind of secret hidden things the code is doing.
|2006-03-31 16:32:38 - In reply to message 1 from Michiel Kamermans|
|As I mentioned, I do not think it is really relevant whether you can call hidden IFrame implementations as AJAX or not, as long it serves for the same purposes. Many people understand what AJAX is by its purposes, not for the underlying methods that are used.|
As for the AJAX solution giving feedback to not bypass the browser, judge for yourself looking at the new login page (logout first):
As I mentioned it can be used to give progress feedback and return a response in the same HTTP request directed to the hidden IFrame.
|2006-03-31 16:55:01 - In reply to message 1 from Michiel Kamermans|
You have a wrong concept here. AJAX isn't a technology, it's a methodology to develop systems. AJAX can use a set of technologies, like DOM + XML + XmlHttpRequest or also ECMA Script + Plain Data + IFrame to handle the methodology; whatever you use, it's AJAX. The term coined by Garrett is unlike because he simplifyed a set of technologies to explain the concept, that mos of people understand as a technology.
> Consequently there is no history to traverse, no data transfer to be stopped, and no status indication of what is actually going on. It bypasses the browser entirely. This is a "Bad thing(tm)".
With IFrame you can handle Back & Forward actions, a thing that you cannot handle using XmlHttpRequest. You can use a hack to handle history, but I doubt people want to implement it because of DB size.
No status: As soon as you recieve some data, you can response back in JS telling the listener that a request is being processed. Whatever, if a response doesn't came in a reasonable time, you can timeout the request or even handle the timeout in such a variety ways, like adding some code in 404, 403, etc pages.
Also, the anoying "tic" problem on IE is answered in the other post.
|2006-04-03 13:00:26 - In reply to message 3 from Guilherme Blanco|
AJAX is a recent term designating a very old set of technologies.
I've used HTTP requests from JS to web server since Netscape 4.03.
XML or not... what's the difference?
XmlHttpRequest object gives You the possibility to use standart HTTP based protocols, such as SOAP and XML-RPC, which is imposible with IFRAME I think. Let's say With Netscape 4 this is perfectly possible as it uses JDK through Java life connect to access the server :)