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 example online (44 messages)
- Posted by: Frank Zammetti
- Posted on: April 02 2005 08:26 EST
Threaded Messages (44)
- Ajax using XMLHttpRequest and Struts example online by Reg Whitton on April 04 2005 07:15 EDT
- Ajax using XMLHttpRequest and Struts example online by analog boy on April 04 2005 09:05 EDT
- Ajax using XMLHttpRequest and Struts example online by ros paredes on June 16 2010 03:48 EDT
- 0x0 Iframes by Keith Casey on April 04 2005 09:46 EDT
- 0x0 Iframes by Reg Whitton on April 05 2005 10:10 EDT
- Similar... by x x on April 04 2005 14:07 EDT
- Another way of doing it... by Nikolay Kolev on April 04 2005 15:04 EDT
- Madre mia by Rolf Tollerud on April 04 2005 04:01 EDT
-
<script src=, Another way of doing it... by Brian Miller on April 04 2005 08:49 EDT
-
<script src=, Another way of doing it... by Dennis Cheung on April 05 2005 02:27 EDT
-
Outlook Web Access by Nikolay Kolev on April 05 2005 08:30 EDT
- Outlook Web Access by Mark N on April 05 2005 09:22 EDT
- Outlook Web Access by Thad Smith on April 05 2005 11:50 EDT
-
Outlook Web Access by Nikolay Kolev on April 05 2005 08:30 EDT
-
<script src=, Another way of doing it... by Dennis Cheung on April 05 2005 02:27 EDT
- Another way of doing it... by Reg Whitton on April 05 2005 10:13 EDT
- Can AJAX be used to logout an user on session timeout by ohIDidntKnowThat ohIDidntKnowThat on April 05 2005 10:16 EDT
- Ajax name origin by Henrique Steckelberg on April 05 2005 10:56 EDT
- Can AJAX be used to logout an user on session timeout by Thad Smith on April 05 2005 12:02 EDT
- Can AJAX be used to logout an user on session timeout by Reg Whitton on April 06 2005 02:51 EDT
- Ajax using XMLHttpRequest and Struts example online by ros paredes on June 16 2010 15:49 EDT
- Ajax using XMLHttpRequest and Struts example online by analog boy on April 04 2005 09:05 EDT
- Why not just use a rich client? by Stuart Ervine on April 04 2005 07:34 EDT
- Agree, Danger by Brian Sayatovic on April 04 2005 08:13 EDT
-
RIA, Agree, Danger by Brian Miller on April 04 2005 12:11 EDT
-
Different means, same end by Brian Sayatovic on April 04 2005 01:30 EDT
- Different means, same end by Brian Miller on April 04 2005 02:58 EDT
-
Different means, same end by Brian Sayatovic on April 04 2005 01:30 EDT
- Investment in webapps... by Stuart Ervine on April 10 2005 04:15 EDT
-
RIA, Agree, Danger by Brian Miller on April 04 2005 12:11 EDT
- Agree, Danger by Brian Sayatovic on April 04 2005 08:13 EDT
- Take a history lesson by Leftie Friele on April 04 2005 07:51 EDT
- Take a history lesson by Jason Gerard on April 04 2005 08:56 EDT
- you got it by Marc Logemann on April 04 2005 10:49 EDT
-
you got it by sundar nambuvel on April 07 2005 12:45 EDT
- everyone got it by null on April 07 2005 11:27 EDT
-
you got it by sundar nambuvel on April 07 2005 12:45 EDT
- Take a history lesson by Patrick Dumontel on April 04 2005 13:26 EDT
- RE: Take a history lesson by Amin Mansuri on April 04 2005 17:53 EDT
-
RE: Take a history lesson by Leftie Friele on April 05 2005 04:25 EDT
- The emperors new clothing by John Brand on April 05 2005 06:18 EDT
- Phat client, RE: Take a history lesson by Brian Miller on April 05 2005 11:18 EDT
-
RE: Take a history lesson by Leftie Friele on April 05 2005 04:25 EDT
- Simple Servlet Example of AJAX and XSLTProcessor by null on April 04 2005 08:20 EDT
- innerHTML by Alf K??re Lefdal on April 04 2005 10:22 EDT
- DOM Level-3 Load&Save, innerHTML by Brian Miller on April 04 2005 12:25 EDT
- forget the x in Ajax by Olivier Allouch on April 04 2005 10:59 EDT
- json-rpc-java by Michael Cohen on April 04 2005 11:35 EDT
- Google seems to like it extended by Olivier Allouch on April 06 2005 05:40 EDT
- json-rpc-java by Michael Cohen on April 04 2005 11:35 EDT
- Ajax using XMLHttpRequest and Struts example online by Mind Bridge on April 04 2005 16:02 EDT
- developer.apple.com article by Stephen Brown on April 05 2005 14:51 EDT
- Ajax using XMLHttpRequest and Struts example online by Muhammad Mansoor on April 06 2005 01:37 EDT
-
Ajax using XMLHttpRequest and Struts example online[ Go to top ]
- Posted by: Reg Whitton
- Posted on: April 04 2005 07:15 EDT
- in response to Frank Zammetti
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. -
Ajax using XMLHttpRequest and Struts example online[ Go to top ]
- Posted by: analog boy
- Posted on: April 04 2005 09:05 EDT
- in response to Reg Whitton
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. -
Ajax using XMLHttpRequest and Struts example online[ Go to top ]
- Posted by: ros paredes
- Posted on: June 16 2010 15:48 EDT
- in response to analog boy
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. -
0x0 Iframes[ Go to top ]
- Posted by: Keith Casey
- Posted on: April 04 2005 09:46 EDT
- in response to Reg Whitton
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. -
0x0 Iframes[ Go to top ]
- Posted by: Reg Whitton
- Posted on: April 05 2005 10:10 EDT
- in response to Keith Casey
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" ? -
Similar...[ Go to top ]
- Posted by: x x
- Posted on: April 04 2005 14:07 EDT
- in response to Reg Whitton
-
Another way of doing it...[ Go to top ]
- Posted by: Nikolay Kolev
- Posted on: April 04 2005 15:04 EDT
- in response to Reg Whitton
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¶m2=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. -
Madre mia[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: April 04 2005 16:01 EDT
- in response to Nikolay Kolev
You never cease to be amazed! -
<script src=, Another way of doing it...[ Go to top ]
- Posted by: Brian Miller
- Posted on: April 04 2005 20:49 EDT
- in response to Nikolay Kolev
For example,<script id="gateway" type="text/javascript"></script>and thengateway.src = "gateway.jsp?param1=value1&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. -
<script src=, Another way of doing it...[ Go to top ]
- Posted by: Dennis Cheung
- Posted on: April 05 2005 02:27 EDT
- in response to Brian Miller
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. -
Outlook Web Access[ Go to top ]
- Posted by: Nikolay Kolev
- Posted on: April 05 2005 08:30 EDT
- in response to Dennis Cheung
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[ Go to top ]
- Posted by: Mark N
- Posted on: April 05 2005 09:22 EDT
- in response to Nikolay Kolev
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. -
Outlook Web Access[ Go to top ]
- Posted by: Thad Smith
- Posted on: April 05 2005 11:50 EDT
- in response to Nikolay Kolev
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. -
Another way of doing it...[ Go to top ]
- Posted by: Reg Whitton
- Posted on: April 05 2005 10:13 EDT
- in response to Nikolay Kolev
Looks good. I assume this will avoid the back button issue. -
Can AJAX be used to logout an user on session timeout[ Go to top ]
- Posted by: ohIDidntKnowThat ohIDidntKnowThat
- Posted on: April 05 2005 10:16 EDT
- in response to Reg Whitton
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:) -
Ajax name origin[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: April 05 2005 10:56 EDT
- in response to ohIDidntKnowThat ohIDidntKnowThat
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 -
Can AJAX be used to logout an user on session timeout[ Go to top ]
- Posted by: Thad Smith
- Posted on: April 05 2005 12:02 EDT
- in response to ohIDidntKnowThat ohIDidntKnowThat
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 -
Can AJAX be used to logout an user on session timeout[ Go to top ]
- Posted by: Reg Whitton
- Posted on: April 06 2005 14:51 EDT
- in response to ohIDidntKnowThat ohIDidntKnowThat
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). -
Ajax using XMLHttpRequest and Struts example online[ Go to top ]
- Posted by: ros paredes
- Posted on: June 16 2010 15:49 EDT
- in response to Reg Whitton
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. -
Why not just use a rich client?[ Go to top ]
- Posted by: Stuart Ervine
- Posted on: April 04 2005 07:34 EDT
- in response to Frank Zammetti
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. -
Agree, Danger[ Go to top ]
- Posted by: Brian Sayatovic
- Posted on: April 04 2005 08:13 EDT
- in response to Stuart Ervine
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. -
RIA, Agree, Danger[ Go to top ]
- Posted by: Brian Miller
- Posted on: April 04 2005 12:11 EDT
- in response to Brian Sayatovic
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. -
Different means, same end[ Go to top ]
- Posted by: Brian Sayatovic
- Posted on: April 04 2005 13:30 EDT
- in response to Brian Miller
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.
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. -
Different means, same end[ Go to top ]
- Posted by: Brian Miller
- Posted on: April 04 2005 14:58 EDT
- in response to Brian Sayatovic
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. -
Investment in webapps...[ Go to top ]
- Posted by: Stuart Ervine
- Posted on: April 10 2005 16:15 EDT
- in response to Brian Sayatovic
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... -
Take a history lesson[ Go to top ]
- Posted by: Leftie Friele
- Posted on: April 04 2005 07:51 EDT
- in response to Frank Zammetti
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. -
Take a history lesson[ Go to top ]
- Posted by: Jason Gerard
- Posted on: April 04 2005 08:56 EDT
- in response to Leftie Friele
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". -
you got it[ Go to top ]
- Posted by: Marc Logemann
- Posted on: April 04 2005 10:49 EDT
- in response to Leftie Friele
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 -
you got it[ Go to top ]
- Posted by: sundar nambuvel
- Posted on: April 07 2005 00:45 EDT
- in response to Marc Logemann
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 -
everyone got it[ Go to top ]
- Posted by: null
- Posted on: April 07 2005 23:27 EDT
- in response to sundar nambuvel
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 -
Take a history lesson[ Go to top ]
- Posted by: Patrick Dumontel
- Posted on: April 04 2005 13:26 EDT
- in response to Leftie Friele
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? -
RE: Take a history lesson[ Go to top ]
- Posted by: Amin Mansuri
- Posted on: April 04 2005 17:53 EDT
- in response to Leftie Friele
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. -
RE: Take a history lesson[ Go to top ]
- Posted by: Leftie Friele
- Posted on: April 05 2005 04:25 EDT
- in response to Amin Mansuri
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. -
The emperors new clothing[ Go to top ]
- Posted by: John Brand
- Posted on: April 05 2005 06:18 EDT
- in response to Leftie Friele
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. -
Phat client, RE: Take a history lesson[ Go to top ]
- Posted by: Brian Miller
- Posted on: April 05 2005 11:18 EDT
- in response to Leftie Friele
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? -
Simple Servlet Example of AJAX and XSLTProcessor[ Go to top ]
- Posted by: null
- Posted on: April 04 2005 08:20 EDT
- in response to Frank Zammetti
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 -
innerHTML[ Go to top ]
- Posted by: Alf K??re Lefdal
- Posted on: April 04 2005 10:22 EDT
- in response to Frank Zammetti
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). -
DOM Level-3 Load&Save, innerHTML[ Go to top ]
- Posted by: Brian Miller
- Posted on: April 04 2005 12:25 EDT
- in response to Alf K??re Lefdal
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. -
forget the x in Ajax[ Go to top ]
- Posted by: Olivier Allouch
- Posted on: April 04 2005 10:59 EDT
- in response to Frank Zammetti
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) -
json-rpc-java[ Go to top ]
- Posted by: Michael Cohen
- Posted on: April 04 2005 11:35 EDT
- in response to Olivier Allouch
-
Google seems to like it extended[ Go to top ]
- Posted by: Olivier Allouch
- Posted on: April 06 2005 17:40 EDT
- in response to Michael Cohen
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 ? -
Ajax using XMLHttpRequest and Struts example online[ Go to top ]
- Posted by: Mind Bridge
- Posted on: April 04 2005 16:02 EDT
- in response to Frank Zammetti
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 -
developer.apple.com article[ Go to top ]
- Posted by: Stephen Brown
- Posted on: April 05 2005 14:51 EDT
- in response to Frank Zammetti
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. -
Ajax using XMLHttpRequest and Struts example online[ Go to top ]
- Posted by: Muhammad Mansoor
- Posted on: April 06 2005 01:37 EDT
- in response to Frank Zammetti
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