On 4/18/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > To get beyond doing the grunt work yourself for Ajax, I recommend taking a > look at this: > > http://dojotoolkit.org/intro_to_dojo_io.html > > and downloading the dojo.io package from their site. > > Personally, I'm not convinced that we need anything new in Struts to make > using Ajax easier. I'm building products today that make extensive use of > the two technologies together, and haven't found a need to enhance Struts to > do it. However, if we do add any Ajax (or Ajax-like) support to Struts, I > want to be able to plug in my plumbing of choice (which would be Dojo right > now) to get the most robust communication scheme available. > > -- > Martin Cooper >
This is exactly the area I've been having trouble with this proposal as well ... tell me again why you can't use Ajax techniques with the standard Struts HTML tags? If you can do it with handwritten HTML pages (which you certainly can), you can also do it with existing Struts HTML tags (or the standard JSF components, for that matter) that offer attributes like "onchange" and "onclick" to plug in your calls to JavaScript methods that do the actual background calls, and then update the client side DOM of your page. It seems to me that a framework can provide value add in primarily the following areas: * Provide a client side JavaScript library that does the grunt work of making the back-end XmlHttpRequest call, and updating the corresponding portion of your DOM. Martin likes DOJO for this; there are also a bunch of other libraries that do the same sort of thing that should be leveraged, instead of inventing something new. * Provide a server side framework that makes it easy to map a particular XHR invocation to the corresponding business logic, and (for extra credit) maps the response data to a generic data format so you don't have to write specific formatting logic for every single response type. I sort of like what JSON provides as a transport protocol, but there's room for value add here on the server side, with a generic data abstraction that maps into the appropriate transport formats. * Provide encapsulated functionality (JSP custom tags, JSF component tags, whatever) that totally hides the fact that Ajax techniques are used into the HTML and JavaScript markup that is automatically generated. If you make the page developer have to do a *lot* more (i.e. a bunch of nested tags) on every Ajax-sensitive component, that doesn't seem to make application development easier ... it only makes it more tedious. Use case to consider -- as an application developer, I want to use a progress bar "widget" that periodically polls the server for the progress of a long running function, and then updates the client side visual representation. If I have to do more than add a single attribute (some way to map to the server side function that returns the completion percentage to be displayed), plus an optional parameter that says how often to check, over what it takes to specify a static image with an <html:img> tag (for example), then I'm likely to say "thanks but no thanks" to your version of that widget. If, on the other hand, you let me say: <html:progressBar progressURL="/filecopy.do"/> or <html:progressBar progressURL="/filecopy.do" interval="3"/> then I'm fat, dumb, and happy. Why should *i* (the application developer) care that you're using XmlHttpRequest behind the scenes? Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
