<snip>Perhaps I'm missing the simplicity of your proposal. Let's take the example from your original RFC. Here it is, for convenience:
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.
My approach is more declarative, that's where it is simpler: less code=simpler, as a generality. Kind of ironic to me that you would be advocating MORE code in a page... isn't that the whole point of a taglib in the first place? Isn't that why we all agree scriplets are Evil Incarnate?
What you demonstrate here I would also argue is worse for page authors, who now have to be concerned with script writing as well as layout of simple HTML tags. You can argue that a page author would know Javascript as well, and you may be right in most cases, but the idea that everyone seems to be pushing is that the page authors should really be glorified graphics artists who just do markup and worry about layout, not code. That doesn't jive, to me at least, with the example you post.
Also in your example you are explicitly constructing the query string... my tags do that for you. I presume you could dynamically create it with Dojo as well, but then your talking about more code. Plus, we're talking a bunch of inline code which, to my eyes, is very ugly, in much the same way anonymous inner classes are in Swing coding.
Come to think of it, at first glance I'm not even sure I understand what is going on in that code! I don't recall ever having seem Javascript done that way, which immediately makes me think twice about this... it's going to be harder to find someone that understand such code than more straight-forward Javascript. I'm sure if I spent two minutes on it I'd get it no problem (looks like a bunch of nested functions, akin to anonymous inner classes in a sense... ugh!)
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.
Yes, those that prefer a declarative approach will like mine better, but isn't that the direction Struts has been moving for years? DynaActionForms, validation, and so on? All of this requires MORE XML, not less. Why would it be any different here?
Also, I'm not sure what you mean about "...need to understand how the URL is constructed"... in fact, all you need to be aware of is what fields in your form you wish to be on the query string, beyond that you have no care at all about it. I didn't get around to implementing the simple XML generator, but the same would be true there. You are simply naming the elements you wish to be submitted, and what key to place them under. I would argue that anyone that knows what an HTML form is would have no problem picking this up.
As far as generated Javascript goes, the same holds true for using someone else' library... What if Dojo isn't working for some reason? Whether the script is generated on-the-fly or part of some external .js file I didn't write, either way I have code to debug that I didn't write. What's the difference? Heck, the same holds true if something in Struts isn't working right! What happens when the script emitted by the validation framework doesn't work quite right? It's the same hassle, but your OK with that I presume? :)
Fair point about the stdInnerHTML thing, but that's just a part of the learning curve that goes along with any new technology. What the hell does the parameter attribute of an Action mapping have to do with using a DispatchAction? Doesn't make much sense at first glance, but you have to do a little learning then it's crystal clear. Same thing here.
Personally, I think I'll stick with the simpler (to me, anyway) Dojo solution. :-)
By all means! :) I never was trying to push this as the One True Ajax Approach, and I believe I said that during the original RFC thread. There are undoubtedly many ways to go about this, and I would be foolish to assume I was proposing the best. I *DO* however still believe my approach has merits that others may not.
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. ;)
Again, by all means, use Dojo. Not everyone will agree it's a good answer though. Not everyone will see it as the greatest thing since sliced bread. Why not offer those folks something else?
Frank
-- 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]
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
