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]
