[ http://mc4j.org/jira/browse/STS-233?page=all ]
Tim Fennell resolved STS-233.
-----------------------------
Resolution: Fixed
Fix Version/s: Release 1.4
I've implemented this for 1.4. The name of the parameter is *not*
configurable. I see no need for the configurability, so the parameter name is
'_eventName', and is specified by StripesConstants.URL_KEY_EVENT_NAME.
It is used as the resolution method of last resort if it is present and no
other method can figure out an event name.
> Event Handler calling using single hidden input
> -----------------------------------------------
>
> Key: STS-233
> URL: http://mc4j.org/jira/browse/STS-233
> Project: Stripes
> Issue Type: New Feature
> Reporter: Ryan Stuart
> Assigned To: Tim Fennell
> Priority: Minor
> Fix For: Release 1.4
>
>
> From mailing list....
> "How about an extension to the AnnotatedClassActionResolver.getEventName()
> and <stripes:form> tag. The new form tag should by default include a new
> hidden field like so:
> <input type="hidden" name="eventHandler" value="">
> The name of this hidden from should be set by an ActionResolver property,
> perhaps ActionResolver.HiddenEventHandlerName? This property should however
> have a sensible default.
> The new AnnotatedClassActionResolver.getEventName() should still do what it
> does currently. However, instead of returning null when it doesn't find an
> appropriate event (using its current searching techniques), it should look
> for the "eventHandler=someValue" parameter in the request. If it is found, it
> should try match the value ("someValue" in the example given) to an action
> bean handler. If it finds a match, it should return the value (ie "someValue"
> in this case) or if no match was found, null.
> This now lets me write the JavaScript code
> "this.form.eventHandler.value='selectedOne';this.form.submit()" in the
> onchange (or any other event) of my select (or some other form component).
> This approach has the advantage of one hidden input for the entire page no
> matter how many selects (or any other form component) i have.
> The only draw back is the need for a rather specific configuration parameter.
> By, if you just default this to something sensible as suggested, it shouldn't
> make it too much of a drama. I have implemented this currently by extending
> the NameBaseActionResolver and FromTag classes but as you can imagine it is a
> little messy. For it to work well and look a lot cleaner, it needs to be
> included in the original source."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://mc4j.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
