On Mon, April 18, 2005 2:13 pm, Joe Germuska said: >>I am not quite sure why "the overhead makes it impractical," unless there >> is >>a physical barrier such as bandwidth restraint -- but that sounds like a >>case-by-case decision is required. > > Well, by definition, an XMLHttpRequest involves a request/response. > I suppose it's true that a blanket statement against is in > appropriate, considering that things like Google Maps do lots of XML > R/R every time you drag the map around.
And the one thing that people tend to forget when thinking about AJAX is that there is nothing that says you have to use XML at all (well, aside from the ACRONYM of course!). It works just as well if you do nothing but query string to the server and simple CSV values back (depending on what your doing naturally). In fact, I don't think any of the examples in my article used XML, at least not submitted to the server. The point is that while you are dead-on Joe, much of that overhead can be alleviated by not using XML at all, seemingly in defiance of the technique in use :) > It seems like validating a date is particularly a case where > JavaScript should be able to do it fine without a network call -- > unless you want to have some kind of scheduler app which checks to > see if a date is "available" or something. No doubt. There are some things that I think people are just plain NUTS for not doing client-side. The format of a date entry is a good example. > Now, you raise a good point as to how the Javascript could capitalize > on the presence of the errorStyle attribute, which normally is only > interpreted on page load. That is, if you did any client side > validation, you'd probably like to be able to switch the style of the > invalid field to whatever was specified in "errorStyle" even if there > was no error when the page loaded. This is valuable outside of the > specifics of an Ajax situation and would also apply to any > client-side validation. Unfortunately, I'm having trouble seeing a > particularly clean way to do it which wouldn't involve loading down > the base tags (because of single inheritance) and even then, I think > you'd have a pretty contentious time getting people to agree on what > the base tags should output. I guess maybe you could have some > Application scoped "input tag decorator" which could be invoked by > the tag if present while still leaving things open for > customization... I actually have some ideas about this Joe, but they aren't completely formed in my brain yet... I'm also not sure any of them will be any good once they are, but if I belive they are I'll post them. What I'm thinking about is the kind of stuff I've done in some of my apps which sound oh so close to what your talking about here... if I can generalize the code I use to do it, then it could wind up being useful to solve this problem. Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
