struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Struts Wiki] Trivial Update of "WhyChain" by JayBurgess
Date Wed, 04 May 2005 14:52:11 GMT
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message