Yes. I agree with this wholeheartedly. I wish we would do something similar with the application specific code that is now in Struts. Plugins would not be the solution, but something akin to that.
On 4/18/05, Hubert Rabago <[EMAIL PROTECTED]> wrote: > 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] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
