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]
