Erik Hatcher wrote:
> - 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.
> - 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.
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?
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.
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.
> 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.
-Ted.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
