In Struts, the view is handled by JSPs and presentation components, the model is represented by Java Beans and the controller uses Servlets to perform its action.
By developing a familiar Web-based shopping cart, you'll learn how to utilize the Model-View-Controller (MVC) design pattern and truly separate presentation from content when using Java Server Pages.
Applying MVC in Servlets and JSP
Many web applications are JSP-only or Servlets-only. With JSP, Java code is embedded in the HTML code; with Servlets the Java code calls println methods to generate the HTML code. Both approaches have their advantages and drawbacks; Struts gathers their strengths to get the best of their association.
Below you will find one example on registration form processing using MVC in Servlets and JSP:
Reg_mast er
Confirm.jsp Error.jsp
If() If()
Controller Servlet
Reg JSP User
UI Components UI Process Components
Service Interfaces
Business
Workflows Business
Components Business Entities
Data Access Logic
Components Service Agents
Data Sources
Services
11In the above application Reg.jsp act as view accepts I/P from client and submits to Controller Servlet.
11Controller Servlet validates the form data, if valid, stores the data into DB
11Based on the validation and DB operations Controller Servlet decides to respond either Confirm.jsp or Error.jsp to client’s browser.
11When the Error.jsp is responded, the page must include all the list of errors with detailed description.
11The above shown application architecture is the model for MVC.
11IF MVC Model 2 wants to be implemented in your application business logic and model operations must be separated from controller program.
View on JSP
The early JSP specification follows two approaches for building applications using JSP technology. These two approaches are called as JSP Model 1 and JSP Model 2 architectures.
JSP Model 1 Architecture
In Model 1 architecture the JSP page is alone responsible for processing the incoming request and replying back to the client. There is still separation of presentation from content, because all data access is performed using beans. Although the JSP Model 1 Architecture is more suitable for simple applications, it may not be desirable for complex implementations.
JSP Model 2 Architecture - MVC
The Model 2 Architecture is an approach for serving dynamic content, since it combines the use of both Servlets and JSP. It takes advantages of the predominant strengths of both technologies, using JSP to generate the presentation layer and Servlets to perform process-intensive tasks. Here servlet acts as controller and is in charge of request processing and the creation of any beans or objects used by the JSP as well as deciding depending on the user’s actions, which JSP page to forward the request to. Note that there is no processing logic within the JSP page itself; it is simply responsible for retrieving any objects or beans that may have been previously created by the servlet, and extracting the dynamic content from that servlet for insertion within static templates.
Limitation in traditional MVC approach
The main limitation in the traditional MVC approach is, in that there is no separation of business logic (validation/ conditions/ anything related to business rules) from controller (is responsible for controlling of the application flow by using static/dynamic request dispatcher.
MVC Model 2 Architecture is Model View Controller
11 Client submits login request to servlet application
11 Servlet application acts as controller it first decides to request validator another servlet program which is responsible for not null checking (business rule) 11 control comes to controller back and based on the validation response, if the
response is positive, servlet controller sends the request to model
11 Model requests DB to verify whether the database is having the same user name and password, If found login operation is successful
11 Beans are used to store if any data retrieved from the database and kept into HTTPSession
11 Controller then gives response back to response JSP (view) which uses the bean objects stored in HTTPSession object
11and prepares presentation response on to the browser Overview of Struts Framework
Introduction to Struts Framework
The goal of this project is to provide an open source framework for building Java web applications. The core of the Struts framework is a flexible control layer based on standard technologies like Java Servlets, JavaBeans, Resource Bundles, and XML, as well as various Jakarta Commons packages. Struts encourages application architectures based on the Model 2 approach, a variation of the classic Model-View-Controller (MVC) design paradigm.
Struts provides its own Controller component and integrates with other technologies to provide the Model and the View.
•
For the Model, Struts can interact with standard data access technologies, like JDBC and EJB, as well as most any third-party packages, like Hibernate, iBATIS, or Object Relational Bridge.•
For the View, Struts works well with Java Server Pages, including JSTL and JSF, as well as Velocity Templates, XSLT, and other presentation systems.•
For Controller, ActionServlet and ActionMapping - The Controller portion of the application is focused on receiving requests from the client deciding what business logic function is to be performed, and then delegating responsibility for producing the next phase of the user interface to an appropriate View component. In Struts, the primary component of the Controller is a servlet of class ActionServlet. This servlet is configured by defining a set of ActionMappings. An ActionMapping defines a path that is matched against the request URI of the incoming request, and usually specifies the fully qualified class name of an Action class.Actions encapsulate the business logic, interpret the outcome, and ultimately dispatch control to the appropriate View component to create the response.
The Struts project was launched in May 2000 by Craig McClanahan to provide a standard MVC framework to the Java community. In July 2001.
In the MVC design pattern, application flow is mediated by a central Controller. The Controller delegates’ requests - in our case, HTTP requests - to an appropriate handler. The handlers are tied to a Model, and each handler acts as an adapter between the request and the Model. The Model represents, or encapsulates, an application's business logic or state.
Control is usually then forwarded back through the Controller to the appropriate View. The forwarding can be determined by consulting a set of mappings, usually loaded from a database or configuration file. This provides a loose coupling between the View and Model, which can make applications significantly easier to create and maintain.
Struts Architecture
Front Controller Context
The presentation-tier request handling mechanism must control and coordinate processing of each user across multiple requests. Such control mechanisms may be managed in either a centralized or decentralized manner.
Problem
The system requires a centralized access point for presentation-tier request handling to support the integration of system services, content retrieval, view management, and navigation. When the user accesses the view directly without going through a centralized mechanism,
Two problems may occur:
Each view is required to provide its own system services, often resulting in duplicate code.
View navigation is left to the views. This may result in commingled view content and view navigation.
Additionally, distributed control is more difficult to maintain, since changes will often need to be made in numerous places.
Solution :