Not necessarily. Some people propose relacing Actions with Commands, but I see Commands as more to do with request processing in general, than request-specific business logic. Instead of a ExecuteAction command that executes a regular Struts Action, you'd have ExecutePOJOAction which calls your own POJO class, similiar to how WebWork and JSF work. Only one ExecutePOJOAction class would exist and it would be part of the processing framework. The POJO action would be request-specific. The key advantage here is your simple actions, that still should delegate processing to facade classes, are now not tied to Struts or even Servlets. You could even perhaps use WebWork actions in a Struts application with no changes.
Again, this are just my ideas for how struts-chain could be used. The flexible and easy to pick up nature of the framework makes it easy for someone else to create their own vision of how Struts should operate, allowing developer community to decide the best approach. Don On Wed, 15 Sep 2004 17:56:29 -0400, Sean Schofield <[EMAIL PROTECTED]> wrote: > > >The best part for developers is commands are very easy to write, and can be easily > >unit tested. > > > > > I'm assuming then that your thinking about replacing most of your > Actions with Commands and the commands would work with POJO's in your > Context right? Would you use a facade as well or would you treat your > chain as a pseudo-facade? > > If we are still talking web applications here how would you get your > info out of the request and into the context? That portion of the code > would still be difficult to unit test right? > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
