You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2001/11/25 15:51:23 UTC

Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons

Erik Hatcher wrote:
> No its not.  What if I want to map several keys to a single method?  That is
> perfectly legitimate use-case where only one minor thing needs to change
> between different key values.

Personally, I would then consider the keys a form of input and make them
part of the ActionForm. 


> What do you mean by "annexed"?  I don't see it anywhere in CVS?

I meant attached.

I haven't a test for the DispatchAction handy, and really can't commit
it without one. Should work though.


-- 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons

Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
> I obviously don't understand the use-case well enough to have a
> reasonable opinion. Needing the keys passed as parameter confuses me,
> since the class already has all that information. Why muddy the
> signature and tell it something it already knows? Everything is
> happening within the same object. Using the original example, the
> parameter "action" is still going to be set to the button's label, and
> any method of the class can look that up whenever they want.

The DispatchKeyAction 'perform' will lookup the appropriate key, and then
dispatch to a method in the subclass.  The subclass 'perform' method won't
know which key was used.  An action should not be using the buttons label
for anything whatsoever - that breaks MVC in a bad way.  Why should the
subclass lookup the key again if it needs it?  What does it hurt to pass the
key to the reflected method?

I envision in our particular application the need to dispatch to several
methods as a form could have several buttons on it to act on the data on the
form.  Some of those actions may not vary much, but having the knowledge of
which button was pressed would be needed to vary the logic to some degree.
It just adds flexibility so that some buttons could map to different
methods, and some to the same method.  Why limit this flexibility when its
easy enough to pass the key parameter also?

    Erik



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons

Posted by Ted Husted <hu...@apache.org>.
Erik Hatcher wrote:
> Oops, sorry.... got it.  I still am lobbying for 'key' to be included in the
> method invoked by DispatchKeyAction.  Pretty please?

I obviously don't understand the use-case well enough to have a
reasonable opinion. Needing the keys passed as parameter confuses me,
since the class already has all that information. Why muddy the
signature and tell it something it already knows? Everything is
happening within the same object. Using the original example, the
parameter "action" is still going to be set to the button's label, and
any method of the class can look that up whenever they want.

-- 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons

Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
> Personally, I would then consider the keys a form of input and make them
> part of the ActionForm.

But then we are back to having the Action have a whole bunch of 'if'
statements for each key.  Sure, a new ActionForm base-class would be handy
to take care of the key lookup, but it doesn't solve the "dispatching"
problem.

The button indicates which "action" to perform, and having the Action class
handle it seems appropriate.  Even with an enhanced ActionForm it would
require coding in Action also.  Why not do it all in a smart Action base
class?

> > What do you mean by "annexed"?  I don't see it anywhere in CVS?
>
> I meant attached.

Oops, sorry.... got it.  I still am lobbying for 'key' to be included in the
method invoked by DispatchKeyAction.  Pretty please?

    Erik



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>