Perhaps I'm missing the simplicity of your proposal. Let's take the example
from your original RFC. Here it is, for convenience:
In the JSP page:
<html:button property="button1" value="Click to do Ajax!"
ajaxRef="button1"/>
In the Ajax config file:
<AjaxConfig>
<ajaxElement>
<id>button1</id>
<event>
<type>onClick</type>
<submitType>queryString</submitType>
<submitItems>buttonValue=button1,textValue=text1</submitItems>
<submitTarget>http://www.omnytex.com</submitTarget>
<returnAction>stdInnerHTML</returnAction>
<returnTargets>resultLayer</returnTargets>
</event>
</ajaxElement>
</AjaxConfig>
Now let's look at the equivalent if I use the existing Struts HTML tags and
Dojo.
In the JSP page:
<html: button property="button1" value="Click to do Ajax!"
onclick="doButton1()"/>
Elsewhere in the JSP page, or maybe somewhere else:
function doButton1() {
dojo.io.bind({
url: "http://www.omnytex.com?buttonValue=button1&textValue=text1";,
load: function(type, data) {
document.getElementById("resultLayer").innerHTML = data; },
mimetype: "text/plain"
});
}
That's all there is to it.
Perhaps for XML-heads, your proposal is easier to deal with. But you still
need to understand how the URL is constructed from the different pieces and
what things like 'stdInnerHTML' mean, not to mention the fun of having
generated JavaScript to debug your problems through, rather than a simple
function call that you wrote yourself.
Personally, I think I'll stick with the simpler (to me, anyway) Dojo
solution. :-)
By the way, while Dojo's goals extend far beyond just dojo.io.bind, one of
the great things about it is that you can just pick up the pieces that you
want. So if all you want is Ajax-like functionality, that's all you need to
include. But if you want a full-blown client side framework, widgets and
all, you can get that too. (Or at least you will when it's done. ;)
--
Martin Cooper
"Frank W. Zammetti" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Tue, April 19, 2005 12:53 am, Martin Cooper said:
> > 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.
>
> It does look cool. However, in some ways what I provided is actually
> better... I have the concept of default return handlers (and default
> submission handlers) that would save the developer, in some percentage of
> situations at least, from writing ANY server-side code whatsoever. True
> enough, one could implement that concept with Dojo too, but then I'm just
> helping develop Dojo!
>
> > Personally, I'm not convinced that we need anything new in Struts to
make
> > using Ajax easier.
>
> Easier for who? For you? You are a super-genius Martin :) It's a
> cakewalk for you. For me too frankly. *I* certainly don't need new tags
> because I don't even use the tags as they are now 95% of the time!
>
> Let's look at it this way... I don't consider the validation framework to
> be any great shakes. I mean, the client-side portion of it anyway. I
> don't need tags that can write validation logic for me. I suspect you
> don't need it either. Was it a bad idea then? Most certainly not! Same
> thing here... if we can provide to 80% of the people a capability that
> requires so very little extra work for them (a single config file and a
> single attribute on any tag involved) that will handle 80% of their needs,
> why in the world wouldn't we jump at the chance?
>
> > 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.
>
> You and I both :)
>
> > 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.
>
> And that is a reasonable point I feel. But, then you get into a situation
> where you have to build something more complex in all probability to
> provide that degree of flexibility... I have to make sure it is generic
> enough to handle any plumbing you want to put in, and then what happens
> when some new plumbing comes down the pipe that doesn't quite fit?
>
> I would rather take the tact "here is an available method to do this AJAX
> stuff, here are the limitations, and when you bump up against them you
> will have to use something else". I just don't see that as a bad thing
> because it helps some people now, as opposed to helping no one, or more
> precisely, leaving them out to entirely help themselves.
>
> P.S. - Take a look at my proposal again... If you really wanted to use
> Dojo, I believe you could with just one minor change: I would have to
> allow for calling custom functions when submitting to the server. This
> was on the slate anyway, and that means you could use your dojo.io.bind()
> stuff here).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
