"Frank W. Zammetti" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Martin Cooper wrote: > > Perhaps I'm missing the simplicity of your proposal. Let's take the example > > from your original RFC. Here it is, for convenience: > > > <snip> > > > > 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?
That's why I said "or maybe somewhere else". It would be perfectly fine to put the JavaScript functions in a separate .js file and <link>ed to from the page. And neither of us are talking scriptlets here. ;-) > 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. Again, move the JavaScript out to a separate file. That's essentially all you've done with your Ajax config file, other than using a new XML syntax for it. Now the only difference between your JSP page and mine is that yours uses customised tags while mine doesn't need them. ;-) > 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. Well, at least going from your example, your construction is little more than string concatenation. I don't think you're saving much. > 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!) Hmm, perhaps we're used to different JavaScript. That's pretty normal stuff to me. Certainly nothing unusual. > > 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? Going from writing ActionForm classes to dyna beans defined in XML saves you a lot of tedious coding. In contrast, this lets you use a *more* verbose syntax to say the same thing. I don't see the advantage. Moreover, if you move the JavaScript code into a separate file, you actually save in clarity and maintainability, at least IMHO. > 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. And my point is that anyone who knows what an HTML form is would wonder why they had to use this new syntax for specifying the URL, instead of just writing the URL in the first place. > 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? :) I'm not referring to the code that does the actuall server call; that's going to be "hidden" code in either approach, as you say. I'm referring to the way in which, in your approach, the 'onclick' function is dynamically generated from your XML config. > 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. Poor fools. ;-) ;-) ;-) -- Martin Cooper > 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]
