http://cvs.apache.org/viewcvs/jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold/FindForwardAction.java
The idea is that you include a "forward=whatever" in the request, and it trundles through the local and global forwards looking for "whatever". So, rather than select a dispatch method, you can select a forward.
Personally, I'd say rather than worry about whether Action is an Interface, that the controller should be able to support more than one type of action class. Ideally, we should be able to extend it to support *any* type of action. But, that's the stuff of 2.x.
Meanwhile, if I wanted to have a base action that could also be or not be a dispatch action, I would probably just rip-off the dispatch mechanism from the original. (Ah, the miracle of open source.) There would be duplicated code between the original and mine, but my application wouldn't be using the original.
If that was still unacceptable, I wager that the dispatch mechanism in DispatchAction could be refactored into a utility class than other Actions could call. Or, it's even possible that the utility code could be moved up into the base Action, so any subclass could use it.
-Ted
Erik Hatcher wrote:
On Monday, March 31, 2003, at 10:01 AM, Brandon Goodin wrote:
I'm curious why you consider it such a problem. It has solved several issues
for me. Quite the opposite. I rarely use the base Action class :-)
LookupDispatchAction itself requires a tighter coupling between what is in the presentation (the button labels) than achieving something like that should. I like Ted Husted's approach in his book better (I don't recall the class name he developed off the top of my head though).
I never extend Action directly either. I like to have a thin layer between actions and Action... with an intermediate BaseAction, which extends Action. But now what happens when you want to use LookupDispatchAction? You can't, cleanly. So then we'd end up with a BaseLookupDispatchAction to maintain that thin layer, and there would be duplicated code.
I suspect there is some way to use aggregation to embed a LookupDispatchAction instance inside a BaseLookupDispatchAction, but my current project does not have forms that have multiple submit buttons, so its not an issue currently.
In other words, inheritance "sucks".... :) thats a bit of harsh and untrue statement, I know, but the point is that its the strongest OO coupling out there, and loosely coupled is the ideal goal, not strongly coupled. Action should be an interface!
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Ted Husted, Struts in Action <http://husted.com/struts/book.html>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
