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]
