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 MichaelJouravlev: http://wiki.apache.org/struts/ComposableRequestProcessor The comment on the change is: Added Ted's notes ------------------------------------------------------------------------------ The RequestProcessor class has been turned into ComposableRequestProcessor that invokes Command in the proper order. This order is defined with standard {{{chain-config.xml}}} file buried deep in Struts library, but can be easily overriden with custom config file if needed. To do this one need to define "chainConfig" property for !ActionServlet in {{{web.xml}}} file. This propertly should contain comma-separated list of either context-relative or classloader path(s) to load commons-chain catalog definitions from. If none specified, the default Struts catalog that is provided with Struts will be used. inline:struts_chain.gif + + 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/Commons Chain is to solve both of these problems: + + * 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 === todo ===
