You are correct Joe, I made no attempt whatsoever to solve that situation. In short (relatively!), for anyone trying to get a grasp on it, my proposal boils down to this:
We have these Struts tags that everyone (except ironically me, most of the time!) uses. These tags have various event handlers attached to them. These event handlers are client-side Javascript functions that do whatever it is they do. We also have this AJAX thingamajig, whereby a client calls on a server, gets a response, and, usually, updates just a part of a web page. Rather than develop a whole new taglib with AJAX at its center (which isn't a bad idea as an aside), why not just modify the existing Struts tags to have some at least minimal AJAX functionality? But what does that really mean? Simply put, instead of calling some Javascript function on the client in response to, say, the onClick event of a button, we instead call a server-side process, get a response back and update some part of the page. The point here is that you continue to use the existing tags that you know and, presumably!, love... your existing pages don't get broken, you don't have to rewrite anything, but you can now introduce this AJAX stuff as needed without having to write all the details yourself. Further, what if what was provided included a number of "standard" functions that would cover maybe 90% of the situations you might want to use AJAX, like updating the innerHTML of a span? What if you could send and received XML, or not, at your discretion? What if the extra cost of all this was an updated JAR, a Struts plug-in, a single new XML configuration file, and an ID added to any form tag you wanted to have this AJAX capability? That, in a nutshell, is my proposal. I was not seeking to recreate the world in an AJAX image, and I was not trying to cover every possible scenario that could arise. My goal was to expand what exists and what people use, giving them some extra functionality they didn't have before. Those that needed more flexibility and power would likely know to look elsewhere, those that had minimal requirements or otherwise didn't have the requisite expertise just yet could stay play with AJAX. I wasn't trying to create a Lexus, just a Yugo :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 1:38 pm, Joe Germuska said: > At 11:15 AM -0400 4/18/05, Benedict, Paul C wrote: >>Frank, will Ajax support be tied into reporting form errors? It would be >>interesting to break down the validator into individual validations, so >>errors can be reported to the user as he types. > > Independent of Ajax, Niall Pemberton has done a substantial overhaul > of commons-validator which will support per-field validation instead > of only onsubmit. > > http://www.niallp.pwp.blueyonder.co.uk/validatorjs.html > > It's really quite impressive, and I think it's only pending Niall > having enough time to really give it a good run-through, since it's a > pretty big change. > > Otherwise, Paul, I'm not sure what you mean... is your idea that an > XMLHttpRequest call would be made to do server-side validation for > each form update? The overhead is likely to make that an impractical > solution. Or are you wondering how errors would be reported back to > the page as a response from an XMLHttpRequest? > > I don't think this is part of Frank's kit (sorry if it is and I > missed it) but it makes sense from a framework standpoint to have > standard XML representations of Struts concepts (like ActionMessages) > paired with a JavaScript library that can convert those into a > standardized JavaScript object model. I haven't tried yet to solve > any problems with Ajax where this would be useful, but it's > definitely the kind of thing you wouldn't want to leave each person > to have to rewrite him- or herself. > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > --------------------------------------------------------------------- > 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]
