As promised earlier today, here is my contribution to the multiple html:submit button saga (Ted, time to update your FAQ! :)....
Here is a breakdown of how to use it:
struts-config.xml segment, note the parameter="action"
<action path="/test"
type="edu.darden.TestAction"
name="TestForm"
scope="request"
input="/test.jsp"
validate="true"
parameter="action">
<forward name="success" path="/results.jsp"/>
</action>
ApplicationResources.properties segment:
button.add=Add Record
button.delete=Delete Record
TestAction.java (extends LookupDispatchAction) segment, the map is keyed by
ApplicationResources.properties
keys, and the value is the method name you want called (with the same
signature as Action.perform):
protected Map getKeyMethodMap(ActionMapping mapping,
ActionForm form,
HttpServletRequest
request) {
Map map = new HashMap();
map.put("button.add", "add");
map.put("button.delete", "delete");
return map;
}
public ActionForward add(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
System.out.println(">>> ADD!!!!!");
return null;
}
public ActionForward delete(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
System.out.println(">>> DELETE!!!!!");
return null;
}
And finally the JSP code segment:
<html:form action="/test">
<html:submit property="action">
<bean:message key="button.add"/>
</html:submit>
<html:submit property="action">
<bean:message key="button.delete"/>
</html:submit>
</html:form>
I recommend the above usage in most cases to cut down on the 'if' statements
and making each unique action clearly defined in separate methods.
But, if there is ever a need to be more general with it, I have provided in
my base class the flexibility to handle dispatching to a single method for
all keys, providing the key to the method. I can only see this being useful
if you have a whole bunch of buttons and there is little difference in the
actions they perform and you only need to do minor logic based on the key.
Here is an example of this, note that if you implement getKeys (and do not
return null) that getKeyMethodMap is not used, so in all but the most crazy
cases would you ever implement both getKeys and getKeyMethodMap. I provided
the mapping, form, and request to these methods just in case someone wanted
to do some dynamic crazy stuff with the array or Map returned from these
methods, but I don't see those parameters being used in most cases.
protected String[] getKeys(ActionMapping mapping,
ActionForm form,
HttpServletRequest request) {
return new String[] {"button.add", "button.delete" };
}
protected ActionForward perform(String key,
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
System.out.println(">>>> key = " + key);
return null;
}
I am out of town for a long weekend tomorrow, so I wanted to get this done
today and get it out to struts-dev for feedback. I plan on providing Cactus
or Deryl's mock test cases for this (but if anyone wants to beat me to
generating those, feel free!) - for this I really just want to verify that
the correct methods get dispatched with the proper key and that error
handling is dealt with appropriately so Cactus isn't necessary. I based it
loosely off of DispatchAction. It would be nice if my invokeMethod was
actually pushed up to DispatchAction to avoid duplicate code and
DispatchAction refactored to use this helper method.
I believe I might have made this class a little too feature-rich and perhaps
it should be broken into two base classes - one to dispatch via reflection
to a Map specified mapping between key and method, and another to do the
dispatching to an enhanced perform method taking the key. With two separate
base classes the getKeys, getKeyMethodMap and perform could all be made
abstract and remove some likely usage confusion.
My Javadoc comments need some work to encompass both ways of using my base
class, but both methods are documented in this message for now.
I welcome feedback and suggestions on this.
Erik
LookupDispatchAction.java
Description: java/
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
