I'm not sure what you're proposing here. If you're looking for feedback on something that might become a Struts extension, for example as part of the Struts SourceForge project, then I would say knock yourself out. ;-) However, if you're proposing this as a future Struts subproject here at the ASF, then I would be against it, for the following reasons:
1) Ajax is just the latest buzzword for something people have been doing with browser based applications for years. It's just a subset of the possible schemes that people use for partial page rendering. By adopting something like this as a Struts subproject, it gives the appearance that Struts is endorsing this one particular approach to the more general problem. That will carry a lot of weight in the Struts community, and since I don't believe that this is the "one true way" (LOTR again ;), that is not something I want to see. 2) Many people are already using existing libraries to build Ajax-like applications. I don't believe that Struts should be providing yet another client-side implementation. If we really want to have an Ajax-like taglib as part of Struts, then it should be capable of using whatever client-side library the developer wants, whether that's Dojo, nWidgets, Burst, f(m) or Zammetti Special. ;-) 3) This seems to me to be a particularly restrictive implementation of the Ajax concept. While it might be possible to expand this to cover all of the possibilities, I suspect that the end result would be horribly complicated, making it much simpler to go back to just using the existing onXXX attributes and defining the rest in JavaScript. -- Martin Cooper On Apr 6, 2005 12:37 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Afternoon all, > > Please reference the code at: > > http://www.omnytex.com/ajaxtags.zip > > 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 looks > something like this: > > 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, > then the prepareAjax() method does it's thing (note that developer-defined > event handler functions will take precedent, so no existing code would be > broken by this). And what is "it's thing"? > > 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]
