Not necessary, but nice.
On another note, there are ways to use AJAX that degrade gracefully to regular form submits and reloads when the AJAX preconditions are not met or ill advised. The dominate AJAX view point at the moment is service oriented: 1) something (even an interval or timeout hook) happens in the browser, 2) a service call is made to the server, and 3) the DOM is possibly modified. There is another way to view AJAX that I believe fits better with existing frameworks like Struts, WebWork, and Spring. Coming from a windowing system view point, AJAX can look like the means of refreshing dirty regions in the page: 1) something happens, 2) the form is "submitted", and 3) any modified regions are rendered and sent back to the browser. You can do all the same things as AJAX-the-service-mechanism plus 1) to the server side it looks just like the same ole form submits, 2) as a result of (1) the page can degrade gracefully to submit/reload, and 3) the application engineer rarely needs to get into JavaScript.
As evidence for my point, the SWF works this way very effectively and is built upon the single primitive of an updateable region. I have ported this primitive to Struts using a very small (8k) tag lib with two trivial tags and no modifications to Struts itself (https:// swf.dev.java.net/docs/Struts.html.) Given this primitive, everything else is possible once one has switched from viewing AJAX as a service mechanism to a means of updating regions in a page. IMO, this direction would be an interesting way to resolve the AJAX/Struts debate in this thread.
Cheers!
On Apr 19, 2005, at 12:47 AM, Craig McClanahan wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
