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/WhyChain The comment on the change is: Added some pictures (will need to refactor the chain docs) ------------------------------------------------------------------------------ the implementation of the new ComposableRequestProcessor class in Struts 1.3. ---- + == Struts 1.0 == + 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. + == Struts 1.1.x - 1.2.x == + 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. + + inline:struts12rp.gif 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. + + == Struts 1.3.x == 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. @@ -28, +36 @@ * 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 :) + 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 + + inline:struts13rp.gif 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. + + inline:struts13rp2.gif + ---- Here is a link to Ted's message in the archives: http://marc.theaimsgroup.com/?l=struts-dev&m=111097810923548&w=2 + Other links: + + http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html + + http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains2.html + + http://www.infonoia.com/en/content.jsp?d=inf.05.06&pr=1 + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
