----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
> > - 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.
>
> I'd like to keep the "dispatch" moniker out of this one, since it makes
> it sounds like it uses the reflective dispatch mechanism. But
> LookupKeyAction works for me. The other could be shortened to
> DispatchKeyAction, if you like.
Sounds good to me. +1
> All that perform knows, that another method would not, is in the
> original signature. I do sometimes extract information from the mapping
> or request, and then pass that back to a method with an extended
> signature, but I think in practice that would be another dispatch
> mechanism, and both techniques would not be used at the same time. Do
> you have a use-case for this feature?
I don't have any use-case for making the getMethod/invokeMethod any more
generalized except that as it exists now DispatchAction is not cleanly
subclassable. Allowing DispatchAction to keep the cache of methods, and to
find methods extensibly so that a method signature is passed into the
getMethod seems like a good refactoring. I can't quite follow exactly how
you are proposing the change, but I'm happy with it if you mean something
along the lines as what I'm saying.
> As it stands, we could extract into another method the fragment from the
> orignal DispatchAction below
>
> "// Identify the method object to be dispatched to"
>
> and pass it the "name" to end the method.
Can't it just take the Object[] of types rather than it being a member
variable of DispatchAction? Then subclasses could take advantage of the
getMethod (String name, Object[] types). The dilemma is then if a subclass
passed in two of the same name's with different signatures - how could we
handle that so that its not possible for a subclass to look for different
signatures, or make the caching mechanism take into account method signature
as well.
Obviously my only use-case/need right now is to have an additional String
key parameter passed to a perform-like method. So I'm ok with locking it
into that method signature if that'll get it committed, but I still think a
DispatchAction subclass should be more extensible than that. Maybe you're
proposing something more extensible and I'm just not seeing it yet though.
> Another class could then extend DispatchAction, override perform, obtain
> its
> own method name in its own way, and then call that same method at the
> end.
I guess I'm just proposing that DispatchAction provide a little more such
that it can handle getting methods in an extensible way, so subclasses don't
have to do as much work. Obtaining the method will be the same for all
except for the signature, right?
> > 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.
>
> Personally, I've started to specify lightweight helper objects as the
> parameter property. A single standard Action can then instantiate and
> invoke these objects from within perform. Additional standard
> functionality is specified through ActionForwards. While this can leads
> to a larger configuration file, it severly reduces the number of Struts
> Actions in the game, and enforces the use of business objects.
Doesn't the decrease in Struts Actions equal the increase in the helper
objects?
Erik
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
