I'm new to struts but the environment I'm coming from Oracle Designer Web PL/SQL generator has a way to deal with this sort of thing that I'm likely to be using in Struts. Every form has a hidden field in it named z_action and the buttons all have some js in the onclick that populates z_action. If you're looking at a record list and at the bottom have a "New" and a "Query" button, the New button sets the value of z_action to "new" and the Query sets the value to "query". This avoids any i18n issues because the button label can be anything and you should be able to put as many buttons as you want. In fact, in the Designer systems that's how First/Previous/Next/Last type functionality is handled (though in this environment I'd use display tags to handle that.
Rick Reumann wrote:
Not sure which list this question/topic really belongs on so posting to both. (I'm bringing it up on the dev list because I'm thinking maybe the base MappingDispatchAction could/should be modified).
Some design background. I like to keep related tasks belonging in one Dispatch Action class (flavor to be discussed). This is a typical approach, yet one of the problems is desided on the type of DispatchAction ... keep it DispatchAction or use one of the subclasses LookupDispatch or MappingDispatch.
First off I really don't like the LookupDispatchAction. I've used it extensively in a large application and it becomes a real pain. It becomes really ugly to use when you start having some generic button names that you reuse for different things. For example a changing requirment was that we ended up having to use a button called "Ok" a lot (I know stupid). So sometimes "Ok" would submit to the same LookupDispatchAction but would need to access different methods. You end up then having to create 'fake' button names in your resources file just so the LookupDispatchAction can work correctly. Maintenance of the LookupDispatch can be a pain also. Anyway...
Until the MappingDispatchAction, I've been relatively content with using a standard DispathAction. What I like about the MappingDispatchAction is that it works really nicely for links - you don't have to append a dispatch parameter name to the URL. It's also nice for typical forms since you don't have to provide a hidden dispatch parameter on the page.
The only problem I'm running into it is when you have a form with more than one button and each button should call a different dispatch method. I haven't really figured out a good way to work this out with the MappingDispatchAction. I think trying to change the form's action attribute using JavaScript will be ugly (assuming it can even be done, I've never tried it). The only solution I can think of at the moment would be to override the getMethodName method of MappingDispatch and provide an extra mapping in your config where the parameter would change to something like parameter="dispatchMethod"
The overridden getMethodName might look like
protected String getMethodName( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response, String parameter) throws Exception {
if( "dispatchMethod".equals( parameter ) { parameter = request.getParameter(parameter); } return parameter }
This would allow you to use the MappingDispatchAction like a DispatchActoin when needed. The only caveat is you would have to make sure the if statement in the above is what you wanted. (Probably better to pull the parameter name "dispatchMethod" from a properties file or constants class).
Maybe there is a much better way to accomplish what I'm concerned with?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
