> -----Original Message----- > From: Erik Hatcher [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 02, 2003 9:17 PM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] WebWork2, here I come! > > > On Wednesday, July 2, 2003, at 05:12 PM, Jason Carreira wrote: > > 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
Heh :-) No. Just a lucky coincidence... > > 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. > > 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. 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. > > > 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 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. Jason ------------------------------------------------------- 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
