Rick, thank you for your thoughtfulness and generosity.
You made me realize that I can set the form action URI as a form bean attribute in my setup Action class, and then, instead of implementing a c:choose switch on a "command" request attribute in my JSP to set the form action URI, I can just use:
<html:form action="${myFormBean.the_action_URI}"/> as you suggested. Yes, I do need to parameterize this URI for the sake of the form validator plugin (as far as I know). But you have improved my code -- tentatively as I haven't actually gotten to this yet :-)
I am not using the MappingDispatchAction as I cannot go to 1.2 yet, but it will be easy to upgrade to it, as I am setting the "parameter" attribute in my action mappings in required fashion. But for now I am simply using an if-else construct that uses String.equals with this parameter to decide which "command" to execute in my Action class (it extends ValidatorAction).
Also, the "trick" you describe below to manually invoke the Validator plugin via a form bean's validate method is clever and useful indeed. I may try that, and definitely will in the case of multiple submit buttons. But still, even with this technique, if you have a single JSP that houses a form that is used for different commands (add, update), you are still going to need two separate form elements in validation.xml, causing redundancy (until "field inheritance" is implemented at least), correct?
Thanks again for your help,
Erik
Rick Reumann wrote:
Erik Weber wrote:
I found the answer. It is to use the struts-el html tag library instead of the standard html tag library, and then to refer to the variable using the expression language syntx:
<c:set var="action" value="/foo/update"/>
. . .
<html:form action="${action}" . . . />
Erik are you uisng one of the DispatchActions (regular DispatchAction, LookUpDipsatcchAction, in 1.2 MappingDispatchAction)? In these cases you could reuse ONE mapping to accomplish your different common tasks and won't need to change the form Action name.
For example, say you were dealing with updating, inderting, viewing Employee information. I would make one DispatchAction called "EmployeeDispatchAction" and in there you'd you have your different methods:
update(..), retrieve(..), maybe even getListOfEmployees(..), etc.
Then your form mapping would simply be something like 'employeeAction', which would result in
<html:form action="employeeAction"> <--- no need for dynamically changing the action attribute
What method gets called inisde of EmployeeDispatchAction is based on the parameter you decide to use (I like to call mine "userAction"). So if using the LookupDispatchAction I have a hidden variable which is set to this variable:
<html:hidden property="userAction"/>
The nice thing is you also shouldn't need to do any logic on JSP either for this, since you can set the "userAction" BEFORE you get to the page in the Action you are coming from (always go through an action:). So for example you click on a menu link called "update employee" - before bringing you to the update employee page you'd first go through a SetUp method in an action and since you know you are then proceding on to the "update" page you simply set the form variable...
myForm.setUserAction(Constants.UPDATE) or myForm.setUserAction("update") or if DynaForm: myForm.set("userAction","update"); or use a Constants.UPDATE
Now I think I remember an earlier discussion where different validations (using the same form) were an issue. In that case having separate action names could be helpful. But even there I'd key the action value based of the parameter for your dispatch action name (no need to do any set or loigic):
<html:form action="${myFormBean.userAction}"> ... </html:form>
And another approach I've used before is a little awkward but it can come in handy and your JSP would even avoid the el above. You'd have one action name (ie action="employeeAction") and of course a dispatch parameter on the page somewhere and which is defined in the action mapping (ie parameter="userAction"). Then you can simply call your form bean's validate method manually. Your formBean would have an over-ridden validate method and it can call the appropriate validator based on the dispatch parameter. It came in handy for a case where I had different submit buttons on one form and depending on which one was selected I had to validate differently. I found it pretty clean. If you ever go this route here's an example...
validation.xml:
<form name="displayFromIndiIds"> <field property="cardStartId" depends="required,integer"> <arg0 key="gc.cardStartId.displayname"/> </field> ...
FormBean with over-riden validate:
validate(..) {
ServletContext application = getServlet().getServletContext();
ActionErrors errors = new ActionErrors();
String parameter = request.getParameter( mapping.getParameter() );
//parameter would be your dispatch parameter ie displayFromIndiIds
Validator validator = Resources.initValidator( parameter, this, application, request, errors, page);
try {
validatorResults = validator.validate();
} catch (ValidatorException e) {
log.error(e.getMessage(), e);
}
return errors;
}
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
