Ted, Attached is my revised and renamed LookupDispatchMethodAction class. It tackles the reflection option, whereas yours tackles the simple perform method invocation. We should unify the two by bringing by:
- Standardizing on the class names. I suggest yours be renamed
LookupDispatchKeyAction, since LookupAction is pretty generic and there will
be several "lookup" style base classes.
- Unifying how we deal with getMethod and invokeMethod into a common
base-class or via a helper utility class. No point in all our classes having
cut and pasted code. My suggestion is to have a common DispatchAction base
class for all of our lookup base classes where the getMethod can be added
more generically in some way. The issue here is, of course, how to deal
with subclasses that want to find different method signatures. I used an
Object[] in my class - maybe thats the way to go, or some derivation
thereof.
- Test cases - I'm as guilty as anyone, but Struts really needs more test
cases. I went looking for them and only found a few test cases in the
Struts CVS, one for ActionServlet, and three tag ones. If there were some
more for Actions and ActionForm's then I would have derived one quickly, but
there are no examples to follow. For this particular class, I'd like to use
Deryl's mock objects one since the main test is to verify that methods are
being dispatched properly. Deryl? Could you get us started on such an
example? I'll give it a shot whenever I get some "down time" to fiddle with
it.
Any comments/suggestions on these items?
I still eventually, if no one beats me to it, want to create another pair of
base classes like this to handle the parameter name changing rather than the
parameter value - this is where the graphical buttons could be handled
automatically by checking for a request attribute "add" or "add.x".
One other comment - I currently prefer using the reflection dispatching
because I'd rather not see a whole bunch of 'if' statements like if
("button.add".equals(key)), but I definitely agree that its useful to have a
more generic dispatch just passing the key.
Thats all for now!
Erik
----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Saturday, November 24, 2001 10:53 AM
Subject: Re: [SUBMIT] LookupDispatchAction - how to handle multiple
html:submit buttons
> 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]>
>
>
LookupDispatchMethodAction.java
Description: java/
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
