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]
