Frank W. Zametti has written an article and accompanying webapp that shows simple usage of Ajax (Asynchronous Javascript + XML), specifically within a Struts application. Mr. Zametti walks through how Ajax is working, why it might be used, and how to apply it in a number of interesting usages of Ajax, including a sortable table and an RSS feed parser, with full code.

Links:

• Ajax using XMLHttpRequest and Struts

I haven't done stuff like this for some years, but I seem to remember that you could do this sort of thing in a browser neutral way that even worked in netscape 4.7. You would use a zero sized inline frame and set the source to load a HTML document that contained your data. The ONLOAD attribute in the loaded page would trigger the update of your SELECT.

However, it always messed the back button history.

a better way is to use javascript to request an image from the server (obviously as small as possible) and attach the request to the cookie then read the parameters from the cookie on the server and send the response back using the cookie. Finally parse the cookie on the client side and you were done.

The weakness with this approach is that you are limited to 4k response, but for a lot of jobs it was a really easy way of sending a request without reloading the whole page.

a better way is to use javascript to request an image from the server (obviously as small as possible) and attach the request to the cookie then read the parameters from the cookie on the server and send the response back using the cookie. Finally parse the cookie on the client side and you were done.

The weakness with this approach is that you are limited to 4k response, but for a lot of jobs it was a really easy way of sending a request without reloading the whole page.

I haven't done stuff like this for some years, but I seem to remember that you could do this sort of thing in a browser neutral way that even worked in netscape 4.7. You would use a zero sized inline frame and set the source to load a HTML document that contained your data. The ONLOAD attribute in the loaded page would trigger the update of your SELECT.However, it always messed the back button history.

Yes, I've been doing this for quite a while. You can use Javascript to push parameters to the pages and even use it to update your main page.

There are a few oddities though as some browsers will show some of the iframe borders no matter the size. The solution here is to use absolute positioning to move it off the viewable screen... -100, -100 always worked for me.

For most of the sites I was doing this on, I would autodetect my login, multiply those by -1, and increase the size to make it useful for debugging purposes.

There are a few oddities though as some browsers will show some of the iframe borders no matter the size. The solution here is to use absolute positioning to move it off the viewable screen... -100, -100 always worked for me.

FRAMEBORDER="0" ?

http://www.josesandoval.com/2005/03/running-xmlhttprequest-with-java.html

One cool way of doing this is thru dynamic change of the src attribute of a script element. It's cool, because it also starts executing the script once it's loaded.

For example,

<script id="gateway" type="text/javascript"></script>

and then

gateway.src = "gateway.jsp?param1=value1&param2=value2...";

It works on both IE and Mozilla and as far as I remember, even on their ancient versions.

I agree that it's not efficient to send XML this way, but the script can dynamically generate JavaScript commands, such as:

selectClear(xyz);
selectAdd(xyz, "1", "Computers");
selectAdd(xyz, "2", "Electronics");

This way you don't even need XML and the Business Logic stays on the server.

You never cease to be amazed!

For example,<script id="gateway" type="text/javascript"></script>and thengateway.src = "gateway.jsp?param1=value1&amp;param2=value2...";

I wondered how XHTML would treat this. The XHTML specification gives an XLink definition of script activation that does not set the "effect=replace" hlink attribute of the script element's src attribute. I'm guessing your script reloading trick wouldn't be so easy with XHTML.

Also I wonder if SVG-2 script src uses XLink? It would be unfortunate if the two leading XULs (XHTML, SVG) had discrepant definitions of script element activation.

I had done something like that long time ago. By using document.createElment("script"), and onload event handle
It only can do a GET request, not a POST,

But there have another big problem. The browser MAY have memory leak.



The reason using XMLHTTP object. It is the only way to do low level http request, which you can handle it. It is safe, security, no addition heavy dependency. And it is cross browser.

I agree! AJAX is much better and I am using it for more than 3 years at work in a product, which supports only IE. By using AJAX, XSL (client-side), and sometimes even XDI (IE's XML Data Islands), we've done some nice things.

I agree that IE has a memory leak, when you use dynamic script loading and it's limited to just "get" method. I am not recommending it at all!

I don't understand why people associate AJAX primarily with Google and "wow" so much about Gmail. Google Maps is something amazing, I agree! But if we have to really "wow" about a flexible and high performance web-based mail client, nothing beats Outlook Web Access that comes with Exchange 2003 (I'm not sure if it uses AJAX, but it seems to)! You simply forget that this is a web application and amazingly it's faster than the desktop Outlook 2003.

But if we have to really "wow" about a flexible and high performance web-based mail client, nothing beats Outlook Web Access that comes with Exchange 2003 (I'm not sure if it uses AJAX, but it seems to)! You simply forget that this is a web application and amazingly it's faster than the desktop Outlook 2003.

You think OWA is fast? Not with IE. It takes a long time to load up (on different machines and different mail servers in different organizations). I mostly use Firefox with it so it will work faster. Of course some of the functionality is gone (like search). I would rather use Thunderbird but I can't always plug up my USB memory stick.

I agree! AJAX is much better and I am using it for more than 3 years at work in a product, which supports only IE. By using AJAX, XSL (client-side), and sometimes even XDI (IE's XML Data Islands), we've done some nice things.I agree that IE has a memory leak, when you use dynamic script loading and it's limited to just "get" method. I am not recommending it at all!I don't understand why people associate AJAX primarily with Google and "wow" so much about Gmail. Google Maps is something amazing, I agree! But if we have to really "wow" about a flexible and high performance web-based mail client, nothing beats Outlook Web Access that comes with Exchange 2003 (I'm not sure if it uses AJAX, but it seems to)! You simply forget that this is a web application and amazingly it's faster than the desktop Outlook 2003.

Outlook Web Access is implemented with ActiveX objects which is why this albeit very cool, "high interactivity" mode only runs in IE. If you open it up in Mozilla you'll find the application doesn't function quite as well, which is of course the Microsoft way of doing things.

Looks good. I assume this will avoid the back button issue.

I have never heard of AJAX before...(Yes...was in a cave...so pardon me:) [[Since I am a soccer nut I thought you folks were talking about the numero uno soccer club of Holland...but I digress..]]

Question:-
Can AJAX be used as a "neater" technology to logout an user from a webpage when his session expires? (I am focused on the term "asynchronous" in the full-form of AJAX)

Well if that is a dumb question...I must be really dumb:)

One possible origin for its name: http://www.in2greece.com/english/historymyth/mythology/names/ajax.htm

There are tons of interesting greek mythologycal names there too, so this could be a good source if you're looking for a name to your brand new open source framework... :)

About the logout thing, I am not sure what you meant. If what you want is some way the server can fire some procedure on the client side, I don't think AJAX will be the answer, as only the client side can start a call to the server, and not the other way around.

Regards,
Henrique Steckelberg

I have never heard of AJAX before...(Yes...was in a cave...so pardon me:) [[Since I am a soccer nut I thought you folks were talking about the numero uno soccer club of Holland...but I digress..]]Question:-Can AJAX be used as a "neater" technology to logout an user from a webpage when his session expires? (I am focused on the term "asynchronous" in the full-form of AJAX)Well if that is a dumb question...I must be really dumb:)

The server would have to have a way of pushing an unrequested message to the browser, letting it know the session had timed out, which is not supported by http. You open up a whole can of worms about firewalls, security, etc just thinking about it.

You could have something on the client side that periodically sends messages to the server to see if the session has timed out, but that would in fact keep the session open! :-)

If a request was sent to the server and the session had timed out, then an appropriate response could be sent to the browser, which would have to have code on how to handle that event, but this would be logout AFTER the session has expired instead of WHEN the session has expired.

"There are no dumb questions, just dumb answers."

Thad Smith

I am focused on the term "asynchronous" in the full-form of AJAX. ... Well if that is a dumb question...I must be really dumb

It's not dumb. I think the "asynchronous" must refer to scripts in a web page making requests to the server and receiving responses without an entirely new web page returned. However, every response from the server is still the result of a request from the client, otherwise we would not be able to do it using the http protocol.

As hinted at by someone above, a page can use a window.setInterval() to keep the session alive on the webserver. This is sometimes called "polling". This allows the session timeout on the webserver to be set very short, and so the user can be registered as logged out almost as soon as the user closes the browser.

To do it the other way around and have the browser close or logout on a timeout is a bit more tricky. You would need your form of timeout, this would need to keep track of the time of the last request (not including the polling requests). The polling request would then calculate if the timeout has expired and when the response is returned to the client, it could then trigger the log out request (probably by requesting a new web page - automatically closing the browser would probably not be allowed).

I haven't done stuff like this for some years, but I seem to remember that you could do this sort of thing in a browser neutral way that even worked in netscape 4.7. You would use a zero sized inline frame and set the source to load a HTML document that contained your data. The ONLOAD attribute in the loaded page would trigger the update of your SELECT.

However, it always messed the back button history.

Likewise I've worked on an application that used this technique, and I couldn't help but wonder why we didn't just write the thing using something like Java Webstart.

I'm still not entirely convinced that the browser is the place to try and write rich clients, especially when it comes to testing the rich interactions that are possible. I also found it takes a lot to get the look and feel up to scratch on a web based rich client (especially between browsers), whereas with Swing (and the likes of JGoodies) it's pretty simple.

Likewise I've worked on an application that used this technique, and I couldn't help but wonder why we didn't just write the thing using something like Java Webstart.I'm still not entirely convinced that the browser is the place to try and write rich clients...

I agree with you, but I fear we're in danger of living in this world. If you look at the number of web app developers out there, and the amount enterprise have invested in web applications, something like this could provide just enough incremental improvement that it will quell the increasing demand for RIAs. I'm not saying it would be as rich, or as good, but this could be woven in to existing web applications a piece at a time, improving them -- satisfying some who would've otherwise wanted RIAs. The end result could be not enough demand for something better.

...especially when it comes to testing the rich interactions that are possible. I also found it takes a lot to get the look and feel up to scratch on a web based rich client (especially between browsers), whereas with Swing (and the likes of JGoodies) it's pretty simple.

I don't think people expect a native look & feel in a web app. In a web app, the native look & feel is a web page, not an application. Give then a more interactive web page and they'll be happy.

I'm not saying it would be as rich, or as good, but this could be woven in to existing web applications a piece at a time, improving them -- satisfying some who would've otherwise wanted RIAs.

I imagine that eventually browsers would support SVG-2 and DOM Level-3 Load&Save, and that could be RIA. The folks best prepared for it would already have become Ajax literate. Ajax isn't a temporary hack until RIA arrives. Ajax is an essential piece of RIA.

I'm not saying it would be as rich, or as good, but this could be woven in to existing web applications a piece at a time, improving them -- satisfying some who would've otherwise wanted RIAs.

I imagine that eventually browsers would support SVG-2 and DOM Level-3 Load&amp;Save, and that could be RIA. The folks best prepared for it would already have become Ajax literate. Ajax isn't a temporary hack until RIA arrives. Ajax is an essential piece of RIA.

Well, I agree that it would achieve RIA, but that is not the RIA vision I and others have. I'd rather see the browser die, or' at most be yet-another-GUI-component in a new rich internet application framework. The browser is a container for web page renderings. I hope that RIAs are run tshrough RIA frameworks that render the applications as top-level GUI windows, not contained within some RIA browser. I don't need a "back button" and "address bar" in my RIA word processor.

That said, I don't think the end user will much care. So long as their experience at least incrementally improves, they'll be excited and happy. To get to my vision, we need a revolution, not evolution. But that people will be largely satisfied with evolution is what threatens to starve support for the revolution.

Well, I agree that it would achieve RIA, but that is not the RIA vision I and others have. I'd rather see the browser die...

SVG is RIA and doesn't need a web browser. Eg, Batik's Squiggle is WebStart deployable -- no browser needed. Whether the browser survives or not is irrelevant. GUIs will likely be encoded as documents, and RIA will likely be document oriented. That's why Ajax is so seminal -- it gives XUL extensible behavior.

If you look at the number of web app developers out there, and the amount enterprise have invested in web applications, something like this could provide just enough incremental improvement that it will quell the increasing demand for RIAs.

Not too sure I'd go for the incremental improvement you've just mentioned... personally I'd rather invest time getting the server side of the app modified so that it could run using either a web browser client, which is not rich, or a Swing/SWT/other rich client.

I also wasn't saying the browser had to mimic a native look and feel, I was really only talking about general layouts, especially when trying to use CSS without tables, and resizing between browsers...

We all tried to do this when IE 4 came out, using hidden frames/iframes and other types of black magic. But, no one does this anymore and why is that? Because it hard to detect errors and debugg applications. Performance was terrible, and chaning the UI became very hard because it was all messed up in the Java Script (which is also the case with the example in this article).

We have been down this road before, there is no reason what so ever to re-open this can of worms. I realy think people should take a brief history lesson before claiming that using the XmlHttpRequest object is the road to heavenly webapplications. When what it realy is, is a a trip down memory lane.

We all tried to do this when IE 4 came out, using hidden frames/iframes and other types of black magic. But, no one does this anymore and why is that? Because it hard to detect errors and debugg applications. Performance was terrible, and chaning the UI became very hard because it was all messed up in the Java Script (which is also the case with the example in this article).We have been down this road before, there is no reason what so ever to re-open this can of worms. I realy think people should take a brief history lesson before claiming that using the XmlHttpRequest object is the road to heavenly webapplications. When what it realy is, is a a trip down memory lane.

XmlHttp can be quite useful, actually. I've used it for a long time before this "Ajax" acronym came about.

I mainly used it when I needed to fetch some data and didn't want to do a full post to the server. Most commonly it was used for dynamic drop down boxes. When you have a drop down that needs different data depending on what was selected. You could send the selection with XmlHttp and then add the response to the drop down without doing a form post.

It was easy to implement and performance was excellent.

I agree with you that the IFRAME hack was a horrible implementation. But XmlHttp can be quite useful if it's not overdone, which seems to be the case with "Ajax".

We have been down this road before, there is no reason what so ever to re-open this can of worms. I realy think people should take a brief history lesson before claiming that using the XmlHttpRequest object is the road to heavenly webapplications. When what it realy is, is a a trip down memory lane.

+1

Leif really got the point about the risks of Ajax and why someone should really have strong arguments using it, other than just playing around and trying to be google.

Marc

Hello,

xmlHttpObject is very useful in certain scenarios. For example , in a application that I developed, there was a necessity to show huge hierarchical data. Instead of fetching the whole hierarchy at one shot (which was not efficient starting from the database level), we implemented that using xmlHttpObject. So once the node is clicked, the children are fetched on the fly !!!!...

Our users are so happy with this solution as

1. The page was not refreshing
2. The page loading was very fast as the initial data displayed is less.

I'm planning to widely use this stuff going ahead. Thinking of one such scenario is sorting tables on click of the headers. The second useful one would be refreshing of a single portlet in a portal application .

-sunda

there are even lots of commercial dhtml based web user interface components available from several vendors. there are several different companies providing comboboxes and others still with complex excel-like data grids that let you do data paging, editing, deleting etc all without refreshing the browser.

these seem necessary for many applications such as financial where they may be editing thousands of records. in that sort of situation if you can reduce the amount of time it takes to edit each record by a factor of 5 you are talking about big time savings! not to mention the fact that it just feels nicer for the end user.

dave

We all tried to do this when IE 4 came out, using hidden frames/iframes and other types of black magic. But, no one does this anymore...

Oh, so Google is no one?

I did take a history lesson:

- Using the technique to grab quick data to make your interface better to use and with less round trips (at least noticeable round trips) has been quite good with my customers

- Gmail. Need I say more?

Of course, reimplementing Swing in Javascript is a bad idea. But Gmail is brilliant.. I wish they would open up their framework.

There is no "magic" in Gmail or Google Suggest. There's just plain old Java Script.
If you do a search you will see theres tons of people who've picked apart the google code, and all you've got is some functions wrapping arround the XmlHttpRequest object. Then you have tons of Java Script outputting HTML.
This was not a good way of doing things last century, and it still isn't.

There is no "magic" in Gmail or Google Suggest. There's just plain old Java Script.If you do a search you will see theres tons of people who've picked apart the google code, and all you've got is some functions wrapping arround the XmlHttpRequest object. Then you have tons of Java Script outputting HTML. This was not a good way of doing things last century, and it still isn't.

My thoughts exactly. But then again, let the emperor be naked, just as long as he keeps out of my backyard.

There is no "magic" in Gmail or Google Suggest. There's just plain old Java Script.If you do a search you will see theres tons of people who've picked apart the google code, and all you've got is some functions wrapping arround the XmlHttpRequest object.

Magic or no, if it blows away the crappy web pages we're coding now, then it still counts as an improvement, likely an evolutionary improvement.

Then you have tons of Java Script outputting HTML. This was not a good way of doing things last century, and it still isn't.

It sure is hell to develop by hand. But if the DHTML is encapsulated and generated by reusable server objects (eg JSF renderers), then it's painless. GMail may have hand coded DHTML, but mainstream DHTML is eventually more likely to be generated when the craft matures. The beauty of DHTML is that it is very easy to generate -- without many of the headaches associated with using BCEL or Janino to generate Java logic. That's because interpreted scripts are easier to generate.

The rise of DHTML doesn't necessarily mean more hand coded DHTML. Eg, Hibernate's generative encapsulation is in many projects eliminating the need for hand coded SQL. SQL is an interpreted language, a thing that can be easily generatively metaprogramed, and Hibernate proves it. DHTML could also be tamed the same way (perhaps as JSF renderers). I absolutely expect this to dominate the fat client arena (by outcompeting Swing/WebStart), especially when XHTML is replaced or combined with SVG-2. XHTML, SVG, and ECMAScript are all international standards that get revised occasionally. Who wants to compete with that?

If anyone is looking for a pure Servlet based (non-struts) example of AJAX and XSLTProcessor then check out this link:
http://www.avedatech.com/technotes/XSLTProcessor.jsp

Wouldn't it be more interesting with a standards based approach to web applications (ref: http://adaptivepath.com/publications/essays/archives/000385.php)?

innerHTML is not a part of DOM (https://www.w3.org/DOM/ or http://www.scottandrew.com/weblog/articles/dom_1).

innerHTML is not a part of DOM

DOM Level-3 Load&Save standardizes features which previously were given as proprietary details such as innerHTML and XmlHttpRequest. RIA amounts to a completely and internationally standardized framework specified by W3C and ECMA.

Any download from JavaScript should use JSON (JavaScript Object Notation) instead of XML. This format is naturally integrated in JavaScript.
On the server side, Java primary types and Collections are marshalled using a simple library. And on the client side, browser independance is managed by an external script.
You still have to use the returned data (using JavaScript Templates for instance) and put the result in the page (with document.write or innerxxx)

See JSON-RPC-Java
(synchronous calls are not recommended, specially using Firefox)

asshat penis extender

I don't specialy disagree with you. If only we could put invisible applets everywhere and use a real language instead of JavaScript. But you indeed feel like you gained a new superpower with a browser independent library.
The real software evolution is when faisible things become easy.
A sentence as an answer ?

For the people interested in XMLHttpRequest, here is also another interesting link showing how easy it is to use that method with Tapestry:

http://www.t-deli.com/ex1/app?service=page/XTileTest

This example implements a simple completion similar to Google Suggest.

On the server side you just have to implement the appropriate listener method (handleCallback() in this example) and you are all set. Please see the source code:

http://www.t-deli.com/xtile-doc/example.html

This article covers similar material to the article http://developer.apple.com/internet/webcontent/xmlhttpreq.html posted on the apple site last year (there is another article on submitting forms remotely, http://developer.apple.com/internet/webcontent/iframe.html, that is also good (and related)). Actually, google was not close to being the first to use this - it seems like they get too much credit; clearly Apple has used this for a while, and Plumtree built it into their portal early last year.

As a side note, d/t strange ActiveX inconsistancies, if you want these techniques to succeed 100% of the time it's good to use IFrame as a 3rd option when the first two don't pan out.

There is nothing new in this article that could help users get a much firm control over this approach. Similiar to the original Apple article