| This Chapter | |
| - | Chapter 1: Model 2 and Struts |
| - | Transfer Objects |
| - | A Primitive Model 2 Application |
| - | Employing View Manager and Action Manager |
| - | Enter Struts |
| - | A Struts Example |
| - | The MVC-ness of Struts |
| - | Summary |
As explained in Introduction, Model 2 is the recommended architecture for all but the simplest Java Web applications. This chapter will now discuss Model 2 in minute detail and provide two examples of Model 2 applications. It will also introduce Struts as a framework for rapid Model 2 application development. This book starts with Model 2 because a sound understanding of this design model is crucial for building effective Struts applications.
Model 2 is based on the Model-View-Controller (MVC) design pattern. The latter was the central concept behind the Smalltalk-80 user interface. At that time the term “pattern” was not yet used. Instead, it was called the MVC paradigm.
An application implementing the MVC pattern consists of three modules: model, view, and controller. The view takes care of the display of the application. The model encapsulates the application data and business logic. The controller receives user input and commands the model and/or the view to change accordingly.
Note
The paper entitled Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC) by Steve Burbeck, Ph.D. talks about the MVC pattern. You can find it at
http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html.
In Model 2, you have a servlet acting as the controller of the MVC pattern. JavaServer Pages (JSPs) are employed as the views of the application. As the models, you use JavaBeans and other Java objects to hold application data and encapsulate business logic. Figure 1.1 shows the diagram of a Model 2 application.
In such an application, every HTTP request must be directed to the controller servlet. A piece of information embedded in the request’s Uniform Request Identifier (URI) tells the servlet what action to invoke. The term “action” is used to refer to an operation that the application must perform.
Figure 1.1: Model 2 architecture
A seemingly trivial function may take more than one action. For instance, adding a product would require two actions:
As mentioned above, you embed a piece of information in the URI to tell the servlet which action to invoke. One way of doing it is by using a request parameter to contain the action information. In this example, to get the application to send the “Add Product” form, the user would type the following URI:
http://domain/appName/Controller?action=displayAddProductForm
To get the application to save a product, the URI would be:
http://domain/appName/Controller?action=saveProduct
Note
The path information can be obtained by calling the getPathInfo method on the HttpServletRequest object. However, if a parameter is used to indicate the action to invoke, you can also use the getParameter method on the same request object.
The controller servlet examines every URI to obtain the path information so that it can decide what action to invoke. Based on the path information, the servlet also determines which view it will pass a request to. If there is business information that needs to be passed to a view, the controller servlet will encapsulate the information in a JavaBean and put the bean as an attribute of either the HttpServletRequest object or the HttpSession object. Finally, the controller servlet uses a RequestDispatcher object to forward the request to the view (JSP). In the JSP, you use custom tags to display the content of the JavaBean.
Adding an object (normally, but not necessarily, a JavaBean) as an attribute of an HttpServletRequest object, an HttpSession object, or the ServletContext object makes the object accessible to custom tags and the Expression Language expressions in a JSP, that is the object can be manipulated without scriptlets. Because of the resulting accessibility, the added object is called a scoped object. The attribute key being used is called a scoped variable.
Suppose you have the following code where request references the current HttpServletRequest object:
ProductBean productBean = new ProductBean();
request.setAttribute("product", productBean);
In this case, you are creating a scoped variable named product that references a ProductBean object. Because you are adding the object to the HttpServletRequest object, the scoped variable and the scoped object can be referred to as the request-scoped variable and the request-scoped object, respectively. Adding an object to the HttpSession object creates a session-scoped variable and a session-scoped object, and adding one to the ServletContext object creates an application-scoped variable and an application-scoped object.
In a moment I will present some examples of Model 2 applications, but first I’d like to discuss the role of the JavaBeans that represent the model of the MVC pattern as transfer objects.