I don't know if we want to step away from extending Action just yet. But, I agree that could step toward using a new interface.
So, we define an "ActionCommand" interface, which is the Command interface but with an ActionContext instead of Context. * Boolean execute(ActionCommand) throws Exception; If the class implements ActionCommand, we call that execute signature. If not, we handle it the Classic way. This could be a class by class election, so people could try ActionCommands without ditching Actions. Likewise, we could also support implementing ActionCommand on an ActionForm. The Action Class could then be omitted altogether, and the processor would call the ActionForm execute instead. Again, this is something people could decide to do on a case-by-case basis. Sometimes it's better to have an all-on-one, sometimes it's better to mix-and-match. We can do both. :) In fact, we could *always* do both. It's not hard to write a standard Action that just calls an execute method on a custom ActionForm class. But now that we have an ActionContext, it's trivial. :) Meanwhile, I would tend to be -1 on deprecating much in the 1.3 series. We should add experimental members for people to experiment with in the field, and then decide where to go in 1.4 and beyond. It might be a good idea to just stop now, stabilize what is already done, maybe do extends for good measure, sort out the website, and ship Core. In terms of future direction, I would also be *very* concerned if we started to add the equivalent of a CoR Catalog to Struts Classic. It's an intriguing idea, but I don't think there is much value-add over using CoR on it's own and just having an Action or ActionCommand call into a user-defined Catalog. It's vital that we encourage people to write the business logic separate from Struts, so it can be tested and used outside of Struts. If we put a Catalog on the Struts layer for application use, then then next thing you know, people are writing business logic against the StrutsContext instead of against their own Context :( IMHO, we should encourage people to make separate and distinct calls to their own Commands, and then use the Action as an adapter between the Application's Commands and the presentation layer. (Envision overlapping circles.) If we make it too easy to bolt your own Chain into an ActionChain, then that's what a lot of people will do. Before you know it, we're back to how do I test the ActionChain outside of Struts? When I work with teams in the field, the hardest sell is convincing people that we should develop "into" Struts rather than "with" Struts. There is a tendency to see Struts as a hammer and everything else as nails. We need to encourage people to see an application as a toolbelt, and Struts as a finishing tool. The "heavy lifting" should be done *outside* of Struts in something like CoR. I'd be leery of anything that gives people the impression that they are writing an application "with" Struts, rather than writing it with CoR and then hooking it up to Struts. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
