-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Erik Weber wrote:
Ah I was just thinking about some web apps I have that basically just refresh combo boxes on POSTs using onchange, one at a time. It would be kind of cool to try to embed some new JavaScript like yours and put some new URLs on the app server to take advantage of this kind of thing, but without breaking anything that works now. So it would use XMLHttpRequest if it was available but not depend on it, to do the refreshing. I'm only thinking out loud so if I'm missing something obvious just ignore me. After all it's Friday. ;-)
Erik
Frank W. Zammetti wrote:
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]
--------------------------------------------------------------------- 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]
