[Struts Wiki] Update of "ActionServlet" by MichaelJouravlev

[Apache Wiki <wi...@apache.org>]

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/ActionServlet

------------------------------------------------------------------------------
+ !ActionServlet provides the "controller" in the Model-View-Controller (MVC) design pattern for web applications that is commonly known as "Model 2".
- Describe the new page here.
- Tested
  
+ !ActionServlet performs the following tasks:
+ 
+  * Identify, from the incoming request URI, the substring that will be used to select an action procedure.
+  * Use this substring to map to the Java class name of the corresponding dispatcher (an implementation of the {{{Action}}} interface or implementation of {{{Command}}} interface).
+  * If this is the first request for a particular dispatcher, instantiate that class and cache it for future use.
+  * Optionally populate the properties of an {{{ActionForm}}} bean associated with this mapping.
+  *
+  * Call the {{{execute}}} method of dispatcher, providing access to the mapping that was used, the relevant form-bean (if any), and the request and the response that were passed to the controller by the servlet container.
+ 
+ == Struts 1.0 ==
+ 
+ In Struts 1.0, request processing logic was entirely concentrated 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, the request processing code was pulled out from !ActionServlet code and turned into a first class object called the RequestProcessor. The original methods remained mainly the same, but they were turned to methods in a coherent object, rather than a set of related methods in a larger object.
+ 
+ == Struts 1.3.x ==
+ 
+ For Struts 1.3, the request processor methods has been turned into Commands, and the !RequestProcessor class has been turned into ComposableRequestProcessor that invokes Command in the proper order. Rather than subclassing a monolithic object, it is possible now just to replace Commands. It is also possible to insert or remove Commands, if needed, to extend or streamline the request processing gauntlet.
+