Struts 2 Interpretation (note-one issue)

Struts 2-- concept article

A request in the Struts 2 process steps:

 

The client submits a (HttpServletRequest) request, as in the previous entry in the browser http://localhost:8080/bookcode/ch2/ Reg.action is to submit a (HttpServletRequest) request.

Requests are submitted to a series of filters (mainly 3 layers) (filter), such as (Actioncontextcleanup, other filters (Sitemesh, etc.), filterdispatcher). Note: Here is the order, first Actioncontext CleanUp, and then other filters (Othter Filters, Sitemesh, etc.), and finally to Filterdispatcher.

Filterdispatcher is the core of the controller, the core of the control layer (Controller) in the MVC 2 implementation.

Filterdispatcher asks Actionmapper if it is necessary to invoke an action to process this request, if Actionmapper decides to call an action, Filterdispatcher the processing of the request to Actionproxy.

Actionproxy the configuration Manager (Struts.xml) to ask the framework's configuration file to find the action class that needs to be invoked. For example, the user registration example will find the Userreg class.

Actionproxy creates a actioninvocation instance, while Actioninvocation invokes the action through proxy mode. However, before the call, Actioninvocation will load all interceptor (interceptors) associated with the action based on the configuration.

Once the action has been executed, Actioninvocation is responsible for finding the corresponding return result based on the configuration in Struts.xml.

The core controller of Struts 2 is Filterdispatcher, which has 3 important methods: Destroy (), Dofilter (), and Init (), which can be found in the download folder of Struts 2.

In the Dofilter () method, Dispatcher.serviceaction is invoked, which, if found, will give the user request to Actionproxy. The Serviceaction () code is in Dispatcher.java.

(Struts 2 is used to handle the action instance of a user request, not the user-implemented business controller, but the action agent.) ）

Struts 2 uses the action Agent, which, depending on the configuration of the system, loads a series of interceptors, which are parsed by the interceptor to pass the HttpServletRequest parameter to the action. Similarly, the result of the action processing is passed through the interceptor to the HttpServletResponse, which is then passed on to the user by HttpServletRequest. In fact, the process is typically a way of AOP (aspect-oriented programming).

Business controller Action

The action is written by the developer, and the action class can be a simple Java class that is completely detached from the servlet API. Action generally has an execute () method, or you can define other business control methods, which are described later in this section.

The action's Execute () returns a string value that is easy to understand compared to the Actionforward returned by struts 1. Struts 2 provides a Actionsupport tool class that implements the action interface and the Validate () method, where the general developer writes the action to directly inherit the Actionsupport class. After writing the action class, the developer must also configure the action in the configuration file. The configuration of an action should contain the following elements: the name of the action, which is the URL that the user request points to. The class element corresponding to the action, corresponding to the position of the action class. Specifies the logical name of the result and the location of the actual resource. The Business Model component uses action to invoke the business logic component to implement in the Execute () method
The business controller action typically does not create a business logic component instance directly, but instead uses the factory pattern or obtains the business logic component instance from the Spring container

View Components

Struts 1 can only support JSP as a view resource, and the progress of Struts 2 is the use of other view technologies, such as freemarker, velocity, and so on. With the previous learning and examples, the reader will know that the return result of the action is just a simple string, a logical view name that must be implemented through a configuration file to correspond to the actual view resource.

In the Struts.xml configuration file, each Aciton definition has the name and Class attribute, and the result element is also specified. The result element specifies the corresponding relationship between the logical view name and the actual view. Each result has a type attribute that does not explicitly specify a type value in the Struts.xml described earlier, using the default type type: Dispatcher, which supports the JSP's so-called view resource.