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]>