Struts

Model-View-Controller (MVC) MVC Model 2

• Model The model contains the core of the application's functionality. The model encapsulates the state of the application. Sometimes the only functionality it contains is state. It knows nothing about the view or controller.
• View The view provides the presentation of the model. It is the look of the application. The view can access the model getters, but it has no knowledge of the setters. In addition, it knows nothing about the controller. The view should be notified when changes to the model occur.
• Controller The controller reacts to the user input. It creates and sets the model.

Model 1: - coupling of controller and view JSP - Controller and a View Java Bean - Model Model 2: decoupling of controller and view delegation of control is easier and therefore decoupling of the view lets you define and choose a technology and implementation for the view that you prefer Servlet - Controller Java Bean - Model JSP (possible others like XSL) - View

1. Different classes in Struts. 2. Objects in struts 3. Steps in Struts with Flow and the Class Figure 5. Struts overview

Struts overview

• Client browser An HTTP request from the client browser creates an event. The Web container will respond with an HTTP response.
• Controller The Controller receives the request from the browser, and makes the decision where to send the request. With Struts, the Controller is a command design pattern implemented as a servlet. The struts-config.xml file configures the Controller.
• Business logic The business logic updates the state of the model and helps control the flow of the application. With Struts this is done with an Action class as a thin wrapper to the actual business logic.
• Model state The model represents the state of the application. The business objects update the application state. ActionForm bean represents the Model state at a session or request level, and not at a persistent level. The JSP file reads information from the ActionForm bean using JSP tags.
• View The view is simply a JSP file. There is no flow logic, no business logic, and no model information -- just tags. Tags are one of the things that make Struts unique compared to other frameworks like Velocity.

UML diagram of the relationship of the Command (ActionServlet) to the Model (Action)

The ActionMapping class An incoming event is normally in the form of an HTTP request, which the servlet Container turns into an HttpServletRequest. The Controller looks at the incoming event and dispatches the request to an Action class. The struts-config.xml determines what Action class the Controller calls. The struts-config.xml configuration information is translated into a set of ActionMapping, which are put into container of ActionMappings. (If you have not noticed it, classes that end with s are containers)

The ActionMapping contains the knowledge of how a specific event maps to specific Actions. The ActionServlet (Command) passes the ActionMapping to the Action class via the perform() method. This allows Action to access the information to control flow.

ActionMappings ActionMappings is a collection of ActionMapping objects.