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]

Reply via email to