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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
