I'll try and clarify things a bit...
First, on the subject of whether taglibs are the goal or not... I have on numerous ocassions said I am not a huge fan of taglibs in general. That is obviously not the popular opinion anywhere other than, oh, say, my own demented mind! But, let's just say I'm not as adamant in that position as I used to be. ;)
Even if I was though, my goal in the beginning was bring this New And Exciting Way-Cool AJAX thing to developers that maybe couldn't or simply didn't want to do it themselves. Coupled with the fact that every Struts developer in the world (except me) already uses the HTML taglib, it seemed obvious that extending them was the way to go, as you say you agree with here.
With way I had implemented the idea in the example I posted, I didn't see a good way to do anything but modify the BaseTagHandler class. I would have (as I recall thinking at the time anyway) duplicate a bunch of code, and I didn't really want to do that. Upon further reflection and after hearing some of the feeback I got, that probably is in fact the better way to go.
As far as integration goes, my thinking was to leave it fairly loose... let me walk through the basic premise by way of an example...
Let's say you have an existing page with two <select> elements on it. Currently, when you change the first, the form is submitted and the server responds with a new page with different contents for the second. Now let's say you decide that AJAX would make this a lot nicer. With what I proposed, you would do the following:
(1) Assign an ajaxRef attribute to the first <select> element.
(2) Create an entry in the new struts-html-ajax.xml config file that maps to that ajaxRef. This entry would contain such things as what events you want to handle via AJAX for the form element, what to do when the event occurs, what form elements to submit with the request, and of course the target of the request.
(3) Create whatever server-side handler is required.
So in this example, we might set ajaxRef="select1" in the <select> tag on the page. Then we might create the following entry in the config file:
<ajaxElement>
<id>select1</id>
<event>
<type>onChange</type>
<submitType>queryString</submitType>
<submitItems>selectValue=select1</submitItems>
<submitTarget>/select1OnChange</submitTarget>
<returnAction>stdPopulateSelect</returnAction>
<returnTargets>select2</returnTargets>
</event>
</ajaxElement>The result would be that when select1 is changed, a request is going to be made to the Action mapping "select1OnChange" with the query string:
?selectValue=xxxx
appended, where xxxx is the value of select1. Your Action would then fire, presumably in this case would generate some sort of return data (probably XML, but that isn't required), and would be returned. the "stdPopulateSelect" would be one of the srandard return actions that would be provided (a developer could develop their own to do more complex things, they just name a Javascript function to call here instead) that knows how to populate the named <select>.
As originally implemented, all the requisite client-side code is actually inserted inline with the element when you add an ajaxRef attribute, but subsequent discussions have convinced me that isn't the best approach (I didn't actually think it was anyway, but certainly any doubt was erased).
So, as it turns out, there really isn't any true integration with Struts, unless you count the plugin that is required for this to work. Oh, I suppose one could envision a new type of Action, kind of a specialized DispatchAction I would think, to handle something like this. I'd have to think about that more though.
So, while I certainly don't consider mysele the innovator, I thought the solution was interesting. Most of the hard work would have been in providing those standard return handlers, as well as a similar thing when transmitting (i.e., I imagined there would be a standard XML generator and such).
But, if you have ideas about how better to do this, feel free to fire them at me. I'm not married to many of the ideas except the core one, the idea of extending the existing tags rather than creating something all-new from scratch. As I said elsewhere, I'm not against that, I find the idea very interesting, but I haven't heard any good, coherent ideas about what form it would actually take, and I admittedly don't have many of my own to offer, so for the time being I'm sticking with the original core idea.
Frank
Fogleson, Allen wrote:
Frank,
Actually, I am a little confused about this. Given that I believe the
quickest (which may or may not necessarily be the best) way to a
solution here is to subclass the current HTML taglibs. Or alternatively
create a new Ajax tagset that incorporates the HTML taglib type
functionality. Yet I thought I saw a post where you said taglibs were
not what you were shooting for.
Maybe you can briefly (or not briefly if you desire) kind of lay out how you see the "integration" happening within struts. Preferably on the client tier and on the server tier. I think I know how I would do it but its good to get it from the innovator :)
Al
--------------------------------------------------------------------- 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]
