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. ;-)
Glad neither of us are talking scriplets :) Didn't think we were anyway, but confirmation is always good!
I agree linking it in is a better answer, and that's one of the changes I intend to make when I complete the work. However, there is still a basic difference of opinion here... you are saying you have no problem with a developer having to write the code that (a) makes the call to the imported library and (b) handles the returned data. My contention is that, at least for some percentage of us cases (I've been saying 80%, may actually be more or less), the tags themselves can be made to do that work automatically. That's the one thing Dojo, or other such options that I've seen, does not address. They provide very nice wrappers around the server call part, and there is most certainly value in that, but they say nothing about what happens when the response is accepted. I belive at last basic things can be provided, hence my notion of the std actions. As long as that's not ALL you can do with it, I see that as a good thing.
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. ;-)
That's really not all that I've done though Martin. You are equating a declarative approach with a shared piece of code. That really is not accurate IMHO. It's like saying that instead of being able to write validation rules in a config file people should instead just simply import some JS library that has all the validation logic in it, and then you just make calls to those imported functions. Same difference.
Why you say my solution requires custom tags I don't understand... yes, it requires custom tags if you aren't already using the Struts HTML tags, and if that's what you meant then I certainly agree with you :) But, since my solution seeks to address people using Struts and the HTML tags specifically, this isn't a limitation.
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.
The code that is emitted it precisely that, true, but it's the fact that you can change what gets concatenating without touching the page that is nice. It's all defined in the config file.
Hmm, perhaps we're used to different JavaScript. That's pretty normal stuff to me. Certainly nothing unusual.
It is an unusual syntax, but that says nothing about it's correctness or anything else. If no one else finds it unusual then just chalk it up to something unusual for me :)
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.
Agreed on the point about moving the JS out... what I plan on doing is having a tag that imports the requisite JS depending on what is done in the tags (I'm frankly not sure how to accomplish this yet, ideally it would be automatic in the <html:for> tag, but as a last resort I can introduce a new tag, something like <enableAjax/> that must be used in the <head> of the page)
I think we have to agree to disagree on which is more verbose though. Your way may save in line count (just barely), but it is at the cost, in my opinion, of a more complex JSP.
> 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.
But the page author wouldn't be worrying about specifying the URL, and even if they did it is the same syntax they specify any other URL with, it's just in an XML file. Perhaps I don't understand your point here?
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.
You may not have quite gotten how this works... as originally written, the code that does the actual server call *IS* hidden, it is just inline in the onClick handler of the tag. Now, as I said earlier, I am agreed that this isn't the best approach (and I thought so originally as well, I believe I mentioned it in the original post). I do think it makes much more sense to import some common code that the event handlers call on. If nothing else it'll save a bunch of extraneous code in the final rendered HTML. But ultimately, putting the actual code duplication aside, there really is little difference...
Frank
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
