Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.
The following page has been changed by JayBurgess: http://wiki.apache.org/struts/WhyChain The comment on the change is: Minor enhancements. Confirmed with Ted. ------------------------------------------------------------------------------ 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. + In Struts 1.1, we pulled out that lump of code and turned it into a first class object called the RequestProcessor. 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.) + Since it was a first-class object, we could subclass this new request processor, and plug in a new one, 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 gauntlet. + For Struts 1.3, we turned the 1.1 request processor methods into Commands. Rather than subclassing a monolithic object, we could now just replace Commands. We could also insert or remove Commands, if needed, to extend or streamline the request processing gauntlet. - 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. + Refactoring the RequestProcessor for Chain of Responsibility (CoR) is about extending the request processing cycle using Commons Chain. 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 to extend 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 problems: + The idea behind CoR and Struts Chain/Commons Chain is to solve both of these problems: * A flexible processing layer for business applications * An extensible request processor for Struts --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
