Erik Hatcher wrote:
> 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.
I think having two base classes here is a good idea. Here's a first
blush at a separate LookupAction that doesn't use the reflection
techniques from DispatchAction.
It's possible that DispatchAction should be refactored so that invoking
the method is separated from determining the method name. This way a
LookupDispatchAction, and others, could determine the method name by
whatever means they like, and then pass that back.
The idea being that the part in DispatchAction below
"// Identify the method object to be dispatched to"
could be moved into another method that would finish up, like
public ActionForward dispatch(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response,
String name)
and the current DispatchAction (or any subclasses) would end with
return (dispatch(mapping,form,request,response,name));
eanwhile, I'm working on adding multibutton submits to "struts-simple"
(which really needs to be renamed), to demonstrate the various
techniques people use, which include
1) Conventional Javascript
2) Javascript via a tag
3) Lookup key from label (annexed)
4) Lookup key from list (not covered in this thread)
5) Lookup key and dispatch
6) Relay to local forward (my personal favorite)
I'm glad this thread came up. I orginally steered clear of
DispatchAction, since it seemed like that the "other" performs would
share a lot of error handling code. I have finally realized that it is
trivial to factor the common code into local methods (keeping everything
on the stack), so that the "other" performs (nomenclature, anyone?)
could really just differ by which business logic method they call.
It also occurs to me that if you wanted to handle something in another
Action, the "other" perform could just return a forwarding to another
Action. So, you can mix and match the "many" versus "few" Action
strategies as needed.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
