I have no problem agreeing that a web SITE probably shouldn't use this. I would even go so far as to say that relatively simple web APPLICATIONS shouldn't use it either. But where to draw the lines makes all the difference.
Most of the apps I've developed over the last few years have been (a) Intranet-only, or extranet to clients, and (b) started with a single requirement at the top of the list: it should generally look, feel and function like a fat-client. Try doing that WITHOUT techniques like this!
(Of course, one could logically ask why the apps weren't true fat-clients with that requirement, but that's another discussion! :) )
Frank
Justin Morgan wrote:
On a slightly tangential note, here's one opinion on XMLHttpRequest usability: http://www.baekdal.com/articles/Usability/XMLHttpRequest-guidelines/
I tend to agree with most, but not all of it.
-Justin
-----Original Message-----
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Friday, March 25, 2005 3:48 PM
To: Struts Users Mailing List
Subject: Re: Best practice for "dynamic reloading" of a part of the JSP
?
I'm not sure I follow Erik... I know I've only used this in Intranet-based applications because of the browser support... No sense locking out anyone using anything but the latest versions (although the version support seems to be better than I had thought frankly)... You can do basically this same thing with a hidden frame as I suggested earlier, so you wouldn't even need XMLHttpRequest, and honestly that's what I've done except for once or twice. That object certainly makes things more concise though.
Frank
Erik Weber wrote:
Thanks for the example. I copied the source. I suppose you could write
some JavaScript that would run on more browsers that would try to
reload
a combo box, but would submit the form if the reload failed? That way you wouldn't have to be as worried about browser support and could possibly work it in to some existing apps . . .
Erik
Frank W. Zammetti wrote:
I'm sure what you've found on the net is sufficient, but in case it isn't, here's a quick example I just threw together:
http://www.omnytex.com/XMLHTTPRequestExample.htm
Note that if a URL you are trying to access isn't in the same domain,
then at least on Firefox you will get an access denied exception.
That example shows two things: retrieving a URL and displaying it in
a
table, and updating the options of a <select> element. I think the later is probably quite applicable.
Obviously you'll want to target some Action rather than an actual URL
as I've done, but the process is identical.
Also, I think it is very important to note that you *DO NOT* have to send back XML, contrary to the objects' name! In fact I've found for
a great many things your life will be considerably simpler to not
send
back XML (such as updating a select like in the example). You need
to
make that determination of course depending on what you are doing. But, XML parsing on the client tends to be a bit on the slow side, so
I wouldn't do it unless you have a reason for it being XML. Especially if you can't be sure you won't be returning a huge
document.
Then again, in a service-oriented world where "services" tends to be synonymous with "web service", which tends to be synonymous with XML,
it's something to think about. Then again, no one said a Web Service
has to be XML-based either! :)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
