On Tue, 15 Mar 2005 20:22:34 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > The idea, I thought, was to use the Commands to supplant the > RequestProcessor with a composable request processor.
In Struts 1.0, requests were processed using a lump of code in ActionServlet. To keep it organized, the code was subdivided in a series of methods. Unsurprisingly, each method in the series had a coherent task and was named after its task. In Struts 1.1, we pulled out that lump of code and turned it into a first class object. The original methods remained mainly the same, but now they were methods in a coherent object, rather than a set of related methods in a larger object. Since it was a first-class object, we could subclass the request processor, and plugin a new one in, without touching the Servlet. (Users do not like to subclass ActionServlet.) We were also able to use a different request processor for each module, if need be. The problem is that it was still an all-or-nothing object. Extensions like Tile and Workflow both needed to subclass the RequestProcessor in different ways for their own reasons. For Struts 1.3, we turned the 1.1 methods into Commands. Rather than subclassing a monolithic object, we could just replace Commands. We could also insert or remove Commands, if needed, to extend or streamline the request processing guantlet. Refactoring the RequestProcessor for CoR is about extending the request processing cycle. It's been a straight-line refactoring since the beginning. I don't believe anyone is trying to follow a particular pattern. We are just trying to provide a flexible approach extending the request processing cycle. Meanwhile, users are forever trying to "chain" Actions. Since most teams do not have a coherent business application framework of their own, they tend to piggyback one on Struts. The input and outputs to their business logic become embedded in Actions, and so they want to chain a "copy" and a "delete" to do a "move". Another use of Commons Chain is that people can use it as the base of their own business application framework (and stop misusing Struts Actions). The idea behind CoR and Struts Chain is to solve both of these problem: * A flexible processing layer for business applications * An extensible request processor for Struts The refactoring of the request processor is a proof-of-concept for CoR. The request processing gauntlet is the "business logic" of the Struts framework. It's also a hoary example of some very nasty business logic. IMHO, if we can do the Struts request processor in CoR, we can do anything in CoR :) Yes, Struts Chain is a challenging application for CoR, and the implementation is not as slick as we might like. But, challenge is a good thing. And, I'm sure as more of us gain experience using CoR in other contexts, we'll devise more elegant solutions. The great thing about CoR is that it's easy to refactor. I'm using CoR in my own applications, and it's working quite well. I hope to start reapplying some of that experience to Struts Chain, and I'm sure others will too. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
