Sheesh! :)
So make the framework set parameters from the <action> element too! Look at Ant's DynamicConfigurator interface for inspiration ;)
See, but there's the problem I had with WW1.x... You had configuration constructs for Commands, but the whole CommandDriven stuff was implemented in ActionSupport. This needs to be core in configuration, and it needs to be core in the framework.
Ya lose me with comparisons to WW1.x since I have never used it, sorry.
I'm still waiting to hear convincing arguments as to why I should change
working code or why I'd want to use class hierarchies.... Having to
subclass things is EXACTLY what I want to avoid... It was a huge hassle
in WW1.x.
But aren't you subclassing something already? ActionSupport? Or your actions are truly POJO's with no base class?
I hear what you are saying loud and clear. I don't want to keep bringing up Struts, as I want to put it out of my mind, but Action in Struts is a base class. Evil! It should have been an interface from the start. Subclassing Action then gets you into trouble because eventually you'll want to leverage ForwardAction, or DispatchAction, or the wonderful LookupDispatchAction :). But since you've done the BaseAction construct you're screwed except for delegation somehow, or doing multiple BaseXXXAction subclasses which is hideous.
You would not need to subclass in WW2 to get dispatching like you want. Implement Action, have a setMethod, and key off method in execute(). I see your point that you'd have to do that in all your actions that dispatch, and thus we're now back to subclassing to centralize.
Can we see what your actions look like and how they work so I can see your use-case (err... user story!)? Most of my web apps simply have a single action and dispatching is not something I've had much need for, but maybe its because my apps are just more simplistic than yours?
Well, this is not exactly the same. I don't want to be loose with data types or anything like that. Reflective method calls are a pretty well understood and low-risk technology.
My main argument against making it truly dynamic like it is now is the cross-referencing needed to find out the flow and how an action is working. Someone (Patrick?) mentioned this earlier. I also like the idea of the _pure_ command pattern. Like I've said though, I'm still learning and your discussion is persuasive. Inheritance is the last OO thing we want to burn up, so I'm in complete agreement with you on avoiding it - this is why I'm cringing with ActionSupport and such.... rather than letting smarter interceptors take care of some of that (like rejecting execute() when validation fails - would making this a parameter on the builtin interceptor be reasonable? Or a separate one to do that?).
Erik
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
