This is how WW1.x command driven actions are implemented. What I don't like about this implementation is that anyone who know a little bit about how WW works can twiddle with URLs to call other methods. Maybe not a huge risk, but just ugly.
This could be prevented with a different interceptor than the Parameter one, or some other interceptor facility to keep ?method=xyz from switching things.
People can choose not to use different methods on their actions, but I
want the ability to use it to keep from having a proliferation of Action
classes.
Its just one DispatchAction though. Where is the proliferation? Subclass that and have at it with all the dynamic entry points you want. I'm still not seeing the drawback to this for you.
I think keeping the Action interface tight, yet allowing implementors to do their own thing if they desire gives us the best of both worlds. Why should the framework itself accommodate this type of dynamic dispatching for you? I'm still not sold. But I'm still listening and *learning*.
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
