[ http://mc4j.org/jira/browse/STS-233?page=comments#action_10540 ] Ryan Stuart commented on STS-233: ---------------------------------
It seems that in version 1.4 and beyond, this has only been half implemented. The parameter "_eventName" is used as the resolution method of last resort if it is present and no other method can figure out an event name, but it isn't included as a hidden field by the stripes:form tag as per the original suggestion. > 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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Stripes-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-development
