What is struts, talk about its working mechanism, and what are its advantages?

1. How does Struts2 handle a user request?

1. First, the user sends a request and intercepts it through the filterDispatcher interceptor.

2. filterDispatcher will ask ActionMapper to determine whether this request needs to call an Action.

3. This ActionMapper encapsulates the requested information. If ActionMapper decides that an Action needs to be called, FilterDispatcher will create a proxy object for the Action based on the information (name of action, name of method called). In fact, the call to Action is implemented through this proxy object.

4. Hand the request to the agent. If the request submitted by the user does not specify a method, then Struts2 will default to the excute method. This agent creates an instance of the scheduler.

This scheduler defines an invoke method, which realizes the interaction of the interceptor and executes the excute method in the Action.

5. The interceptor is called in the form of value stack.

Struts2 has 18 interceptors by default. The first interceptor is an exception interceptor. In this case, if my first interceptor catches the exception, then I will not need to catch exceptions that occur in other interceptors in the future.

6. After the Action is executed, the scheduler will be responsible for finding the corresponding return result based on the configuration in struts.xml.

7. Then the scheduler returns all interceptors and returns the result set to the client through response.

Second, the difference between Struts2 and Struts1

Action class:

Struts1 requires the Action class to inherit an abstract base class. A common problem with Struts1 is programming with abstract classes instead of interfaces.

The Struts 2 Action class can implement an Action interface or other interfaces, making optional and customized services possible. Struts2 provides an ActionSupport base class to implement commonly used interfaces. The Action interface is not required. Any POJO object with the execute identifier can be used as the Action object of Struts2.

Thread mode:

Struts1 Action is a singleton mode and must be thread-safe, because only one instance of Action handles all requests. The singleton strategy limits what Struts1 Action can do, and requires special care when developing. Action resources must be thread-safe or synchronized.

The Struts2 Action object generates an instance for each request, so there is no thread safety issue. (Actually, the servlet container generates many discardable objects for each request and does not cause performance and garbage collection problems)

Servlet dependencies:

Struts1 Action depends on the Servlet API , because when an Action is called, HttpServletRequest and HttpServletResponse are passed to the execute method.

Struts 2 Action does not depend on the container, allowing Action to be tested independently of the container. Struts2 Action can still access the original request and response if needed. However, other elements reduce or eliminate the need to access HttpServetRequest and HttpServletResponse directly.

Testability:

A major problem with testing Struts1 Actions is that the execute method exposes the servlet API (which makes testing dependent on the container). A third-party extension - Struts TestCase - provides a set of Struts1 mock objects (for testing).

Struts 2 Action can be tested by initializing, setting properties, and calling methods. "Dependency injection" support also makes testing easier.

Capturing input:

Struts1 uses ActionForm objects to capture input. All ActionForms must inherit a base class. Because other JavaBeans cannot be used as ActionForms, developers often create redundant classes to capture input. Dynamic Beans (DynaBeans) can be used as an alternative to creating traditional ActionForms. However, developers may be re-describing (creating) existing JavaBeans (still resulting in redundant javabeans).

Struts 2 uses Action properties directly as input properties, eliminating the need for a second input object. Input properties may be rich object types with their own (sub) properties. Action properties can be accessed through taglibs on the web page. Struts2 also supports ActionForm mode. Rich object types, including business objects, can be used as input/output objects. This ModelDriven feature simplifies taglib's reference to POJO input objects.

Expression language:

Struts1 integrates JSTL, so it uses JSTL EL. This EL has basic object graph traversal, but support for collections and indexed properties is weak.

Struts2 can use JSTL, but also supports a more powerful and flexible expression language-"Object Graph Notation Language" (OGNL).

Bind values ??to the page (view ):

Struts 1 uses the standard JSP mechanism to bind objects to the page for access.

Struts 2 uses "ValueStack" technology to enable taglib to access values ??without binding your page (view) to the object. The ValueStack strategy allows reuse of pages (views) through a series of properties with the same name but different types.

Type conversion:

Struts 1 ActionForm properties are usually of String type. Struts1 uses Commons-Beanutils for type conversion. One converter per class, not configurable per instance.

Struts2 uses OGNL for type conversion. Provides converters for basic and commonly used objects.

Validation:

Struts 1 supports manual verification in the validate method of ActionForm, or verification through the extension of Commons Validator. The same class can have different verification contents, but sub-objects cannot be verified.

Struts2 supports verification through the validate method and the XWork verification framework. The XWork validation framework uses the validation and content validation defined for the attribute class type to support the chain validation sub-property

Action execution control:

Struts1 supports each module with Separate Request Processors (lifecycle), but all Actions in the module must share the same lifecycle.

Struts2 supports creating different life cycles for each Action through Interceptor Stacks. Stacks can be used with different Actions as needed.

Third, the Struts2 framework loads Struts2 constants in the following search order:

struts-default.xml is saved in struts2-core-version.jar

struts-plugin .xml is saved in struts2-Xxx-version.jar

struts.xml The default Struts2 configuration file for web applications

struts.properties The default Struts2 configuration file for web applications

< p>web.xml web application configuration file

If the same Struts2 constant is configured in multiple files, the constant value configured in the latter file will overwrite the constant configured in the previous file.

Four, when struts2 encounters a type conversion error, struts2 automatically generates an error message and automatically puts this error message into addFieldError

Fifth, here, there may be some Readers will ask questions, why are good Servlet objects encapsulated into Map objects here? I think there may be two reasons:

1. Completely shield the Servlet container from the Struts2 Action, eliminating the need to use the underlying Servlet API for programming. What you face will always be one Java object after another.

2. Facilitate various View technologies, such as JSP, Freemarker, Velocity, etc., to read the context environment in ValueStack, especially the data in the Servlet object. Just imagine, if we do not convert Servlet objects such as HttpServletRequest and HttpSession into Maps here, it will be difficult for us to read the values ????in these Servlet objects through OGNL expressions.

6. Verify validate. First execute the validateMethod method and then execute the validate method execute method validateExecute()

7. Field verification (commonly used) and non-field verification

Client-side verification: 1. The theme of the form must not be set to simple

2. Set the validate attribute of the form to true

It is best not to use struts2 The client verification methods we provide

Eight, fieldError

1. The information object actually stored in the field level error is LinkdedHashMp

2. The LinkedHashMap The key is of type String and the value is of type ArrayList

3. Action-level error messages are actually placed in ArrayList

Nine, interceptor interceptor stack< /p>

We can imagine struts2 as a container, configured with many interceptors, and then called layer by layer

The interceptor configured first is executed first, and the interceptor configured first comes out last (incoming and outgoing)

has a higher priority than

Ten, model-driven

paramsPrepareParamsStack is a wonderful interceptor stack in Struts 2.0, so many people wonder why it is not included Set as the default interceptor stack. paramsPrepareParamsStack mainly solves the problem of cooperation between ModelDriven and Preparable. Literally speaking, the order of calling the interceptor of this stack is: first params, then prepare, then modelDriven, and finally params. The design of Struts 2.0 requires modelDriven to be called before params. In business, prepare is responsible for preparing the model, and preparing the model requires parameters. This requires running the params interceptor to set relevant parameters before prepare. This is the reason for creating paramsPrepareParamsStack.

The process is as follows:

1. The params interceptor first assigns values ??to the relevant parameters in the action, such as id

2. The prepare interceptor executes the prepare method, and the prepare method will be based on the parameters, such as id, to call the business logic and set the model object

3. The modelDriven interceptor pushes the model object into the value stack. The model object here is created in prepare

4. params The interceptor then assigns the parameters to the model object

5. The business logic of the action is executed based on this stack

Eleven, the coupling part between sturts2 and Servlet

(1 )ActonContext.getContext() (Convert request, session, etc. into map, convenient for testing, but there is no httpresponse interface)

(2) ServletResponseAware, ServletRequestAware interface implement setServletResponse() method, servletResquest() method respectively

The Struts2 framework automatically sets the request object related to the container into the application. This is a typical IOC

(3) ServletActionContext can be obtained by directly calling the static method request and other objects

It is recommended to use the first method, because although it is coupled with the servlet, the servletAPI does not really appear, and the entire action is still very clean. If you want to use httpresponse, you can use the third method.