Model-view-controller (MVC) pattern with Struts
In Model-view-controller (MVC) pattern, we described the general concepts and architecture of the MVC pattern. Figure | 5-1 shows the Struts components in relation to the MVC pattern:
| Model: Struts does not provide model classes. Specifically, Struts does not provide the separation between the controller and model layers. The separation must be provided by the Web application developer as a facade, service locator, EJB, or Java Bean.
|
|
| View: Struts provides action forms (or form beans) in which data is automatically or manually collected from HTTP requests with the purpose to pass data between the view and controller layers. In addition, Struts provides custom JSP tag libraries that assist developers in creating interactive form-based applications using JSPs. Application resource files hold text constants and error message, translated for each language, that are used in JSPs.
|
|
| Controller: Struts provides an ActionServlet (controller servlet) that populates action forms from JSP input fields and then delegates work to an action class where the application developer implements the logic to interface with the model.
|
Figure 15-1 Struts components in the MVC architecture
A typical Struts Web application is composed of the following components:
|
| Action servlet-A single servlet (extending org.apache.struts.action. ActionServlet) implements the primary function of mapping a request URI to an action class. Before calling the action class, it populates the action form associated to the action with the fields from the input JSP. If specified, the action servlet also requests the action form to validate the data. It then calls the action class to carry out the requested function. If action form validation fails, control is returned to the input JSP so the user can correct the data.
The action servlet is configured in the Web deployment descriptor (web.xml). The action servlet controls and manages the relationship between other Struts components which is configured in the Struts configuration file (struts-config.xml).
|
|
| JSPs-Multiple JSPs that provide the end-user view. Struts includes an extensive tag library to make JSP coding easier. The JSPs display the information prepared by the action classes and requests new information from the user.
|
|
| Action classes-Multiple action classes (extending any one of the Struts action classes like org.apache.struts.action.Action) that interface with the model. When an action has performed its processing, it returns an action forward object, which determines the view that should be called to display the response (or alternatively forward to another action class). The action class prepares the information required to display the response, usually as an action form (although, it is not recommended), and makes it available to the JSP. Usually the same action form that was used to pass information to the action is used also for the response, but it is also common to have special view beans tailored for displaying the data. An action forward has properties for its name (logical mapping), path(URI), and a flag specifying if a forward or a send redirect call should be made. The address to an action forward is usually externalized in the Struts configuration file, but can also be generated dynamically by the action class.
|
|
| Action forms-Multiple action forms (extending one of the Struts action form classes like org.apache.struts.action.ActionForm) to help facilitate transfer form data from JSPs. The action forms are generic JavaBeans with getters and setters for the input fields available on the JSPs. Usually there is one form bean per Web page, but you can also use more coarse-grained form beans holding the properties available on multiple Web pages (this fits very well for wizard-style Web pages). If data validation is requested (a configurable option) the form bean is not passed to the action until it has successfully validated the data. Therefore the form beans can act as a sort of firewall between the JSPs and the actions, only letting valid data into the system.
|
|
| Resource files-One application resource file per language supported by the application holds text constants and error messages and makes internationalization easy.
|
Figure | 5-2 shows the basic flow of information for an interaction in a Struts Web application.
Figure 15-2 Struts request sequence
The following processing takes place:
|
| A request from a Web browser is first received by the Struts action servlet.
|
|
| If the action that handles the request has a form bean associated with it, Struts creates the action form and (and if specified, automatically) populates it with the data from the input form.
|
|
| It then calls the validate method of the action form. If validation fails, the user is returned to the input page to correct the input. If validation succeeds, Struts calls the action's execute method.
|
|
| The action retrieves the data from the form bean and performs the appropriate logic. The action often calls session EJBs to perform the business logic.
|
|
| When done, the action either creates a new action form (or other appropriate view bean) or reuses the existing one, populates it with new data, and stores it in the request (or session) scope.
|
|
| The action then returns a forward object to the action servlet, which forwards to the appropriate output JSP (or alternatively forwards to another action).
|
|
| The JSP uses the data in the action form to render the result.
|