No problemo. As far as the extension itself is concerned, I'd still be interested in it, but like I mentioned earlier, only as a plugin that doesn't change the base tags. The reasons are many and they are mentioned in the dev thread you started. My main concern is implementation lock-in. Another message in this thread already illustrates that there could be several approaches to adding this functionality. I wouldn't want to limit how everyone else applies the technology. As Martin said, if an implementation is built into Struts, it should support whatever client-side library the developer would want to use ( http://marc.theaimsgroup.com/?l=struts-dev&m=111284722931074&w=2 ). A separate plugin wouldn't have to have that burden.
A separated plugin would result in code duplication, true, but in my view it's worth it. In some aspects, the ajax-aware tags you propose are in a better position than the EL tags. You only need to override some methods, whose implementation can be moved to a util-type class. EL had to add duplicate fields, getters, and setters. Just take a look at the source of some of those tags, like ELCheckboxTag and ELRadioTag. Hubert On 4/18/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Yep, sorry about that... I had it in my drafts folder because I got called > away in the middle of it, and I didn't check all the replies to the > current thread before sending it so I didn't see your link until > afterwards. My bad :) > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > On Mon, April 18, 2005 10:41 am, Hubert Rabago said: > > Frank, > > > > You must've started typing this response a while ago. I already sent > > a message on this thread linking to the dev email with your proposal. > > > > Hubert > > > > On 4/18/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > >> On 4/6 I posted the following message to the Struts dev list... I can't > >> seem to find the thread in the list archives, if anyone else can I would > >> appreciate very much you posting the link to it... > >> > >> This was discussing my proposal for integrating AJAX functionality into > >> the existing Struts taglibs. There were some legitimate dissenting > >> points > >> raised about this, and ultimately the idea was shot down. However, I > >> still feel the idea has significant merit. > >> > >> The proposal wasn't posted to the user list, and maybe I should have > >> done > >> so... if there is support for this in the user community, I would be > >> willing to persue it further and provide it as part of the SF Struts > >> project. > >> > >> P.S., I've added some notes here for some things that may not be as > >> clear > >> as I would have liked, especially if you aren't terribly familiar with > >> the > >> Struts code base, so if you see minor difference between this and what > >> is > >> in the archives, that's all it is... > >> > >> -------------------- > >> > >> Subject: RFC: Struts HTML Ajax-Aware Tags > >> > >> Afternoon all, > >> > >> Please reference the code at: > >> > >> http://www.omnytex.com/ajaxtags.zip > >> > >> This is a complete webapp demonstrating the proposal (it isn't complete, > >> it is just to get the ideas across). > >> > >> I wanted to put something out there in front of you all and get some > >> feedback on it before I go that extra mile and finish it out. > >> > >> This came out of some ideas I tossed at Ted a few days ago. The basic > >> idea is to take the existing Struts HTML taglib and make the tags > >> Ajax-aware. > >> > >> In a nuthsell, take a simple button tag... > >> > >> <html:button property="button1" value="Click to do Ajax!" /> > >> > >> ...now, add a new attribute to it, ajaxRef: > >> > >> <html:button property="button1" value="Click to do Ajax!" > >> ajaxRef="button1" /> > >> > >> When the tag is rendered, each possible type of event handler (in the > >> BaseTagHandler class) looks something like this now: > >> > >> if (getOnclick() != null) { > >> handlers.append(" onclick=\""); > >> handlers.append(getOnclick()); > >> handlers.append("\""); > >> } > >> else { > >> prepareAjax("onclick", handlers); > >> } > >> > >> prepareAjax() does a lookup to a new XML configuration file (well, > >> in-memory objects representing the XML of course!) like so: > >> > >> <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> > >> > >> If an <ajaxElement> with an <id> matching the ajaxRef attribute is > >> found, > >> and if an <event> with a <type> matching the type being added to the tag > >> is found, then the prepareAjax() method does its thing (note that > >> developer-defined event handler functions will take precedent, so no > >> existing code would be broken by this). And what is "its thing" you > >> ask? > >> > >> Basically it will add an inline event handler to the tag, just like > >> always, that is capable of making an Ajax request (using the > >> XMLHttpRequest component). A quick description of the XML elements > >> pertaining to <event> should bring this in to focus: > >> > >> type .. is of course the type of event handler. It can be any of the > >> types that the BaseHandlerTag handles. > >> > >> submitType .. is the type of submission that will be made. Two types > >> are > >> (will be) supported: queryString and XML. > >> > >> submitItems .. is a comma-separated list of form elements and the names > >> they should be given. For instance, in the example above we would get a > >> query string in the form ?buttonValue=<1>&textValue=<2> where <1> is the > >> value of the button on the page and <2> is the value of the textbox on > >> the > >> page. > >> > >> submitTarget .. is the URL the request is submitted to. This can be a > >> relative path or a full URL (although full URLs will of course incur the > >> cross-site scripting restrictions) > >> > >> returnAction .. is what will happen when the request returns. There > >> will > >> be a number of built-in actions, all prefixed with "std' (let's get all > >> the disease jokes out of the way now!). You can also name a page-level > >> Javascript function here to do other things. > >> > >> returnTargets .. is a comma-separated list of elements on the page that > >> will be affected by the action. This will generally be required for the > >> standard actions, and is up to the developer if they want it if writing > >> their own function. > >> > >> The code you hopefully downloaded is a sample webapp, very simple. > >> Click > >> the button to retrieve the Struts web site and dump it in a span. Note > >> that if you are in an environment that requires a proxy for network > >> access, you will need to set the httpProxy and httpPort elements in > >> web.xml appropriately. It is by default set up assuming no proxy is > >> required. > >> > >> The example has a number of quick-and-dirty type hacks just to > >> demonstrate... for one, the XML config file is NOT read in, instead the > >> objects are just populated manually in AjaxInit (which is a Struts > >> plug-in > >> and is required to make the tags Ajax-aware). Second, the query string > >> is > >> currently not actually built, it's just hard-coded. Third, only the > >> queryString submitType is recognized. Fourth, only the stdInnerHTML > >> returnAction is recognized (as the name implies, this just sets the > >> innerHTML of any elements named in returnTargets). And lastly, there is > >> very little commenting or proper error handling in spots. > >> > >> Like I said, a very simple example, but I think it gets the point > >> across. > >> > >> Also included is the change to BaseTagHandler, the only altered class > >> from > >> the taglib (no Struts core changes, as one would expect). As I > >> mentioned, > >> there is a plug-in required for this, and there are a total of six new > >> classes, all dealing with storing the configuration information. > >> > >> So, the question is, does anyone see this as something interesting? Is > >> anyone interested in seeing this actually finished up? If so I can do > >> that, probably by the weekend if things go well, and I suppose open a > >> ticket for it at that point. > >> > >> Questions? Comments? Whatever? Thanks all! > >> > >> -- > >> 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] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
