converted to 1.6 markup
|No differences found!|
ActionServlet provides the "controller" in the Model-View-Controller (MVC) design pattern for web applications that is commonly known as "Model 2".
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.
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.
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.