Well, the drawback is that now you need a hack interceptor to intercept
attempts to misuse the dispatch action... Plus, the DispatchAction feels
very... Struts :-)
Uh.... damn.... did you look at @author tags in the Struts codebase to pick on me?! :) (yes, I'm the original author of LookupDispatchAction - which is designed to handle multiple submit buttons for a single form). I never use LDA in my code, though.... it was written because a very lame consultant was hard-coding button labels into Struts actions:
if ("Add Item".equals(label)) {.... } // and so on
I had to do something to keep the codebase from becoming so fragile and coupled with text labels. Our current app doesn't have forms with multiple submit button paths - but its a scenario that needs to be addressed certainly.
Seriously, being able to specify the method to call in the action element is much more clear to me than setting a method param...
Sheesh! :)
So make the framework set parameters from the <action> element too! Look at Ant's DynamicConfigurator interface for inspiration ;)
This is in there for the same reason IoC is in Xwork. These are
different styles of programming that have proven to be valuable, so they
are supported in the core framework. If you have multiple buttons on a
page that do different things, do you really want to have n different
commands for it all extending from a common base class?
Absolutely not. Again, my vote here is to use a dispatching action under the covers, with still a single point of entry from the webwork side of things. I'm still eagerly tuning in to find convincing arguments otherwise. This is a fun discussion, in fact. Amazing how different views can be on what is a seemingly trivial issue.
There are other patterns of use that can be implemented with Interceptors and class hierarchies as well, and if they prove to be valuable, they'll be incorporated into the core framework as well.
Cool... in fact that is great.
My vote for a tight interface and contract with Action/execute stems from my experience with Ant (and surely Struts in some way). Ant plays extremely loose with datatypes/tasks and I think it would have been better to have it tightened up there as well to make things more explicit. It is quite cool what Ant does with introspection, though, and it leads to rich expressiveness in types used in tasks... yet there is still public void execute() as the single entry point for them all.
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
