[Learn struts2 step by step with me] -- interceptor

Preface

As mentioned earlier, the interceptor can only intercept action. Here, the interceptor calls reflect the responsibility chain mode. Why does it reflect the responsibility chain model?

 

The following is a clear explanation:

Struts2 divides the entire execution into several elements of the same type. Each element has different logical responsibilities and is incorporated into a chained data structure, each element is responsible for executing and calling the next element in the chain structure.

From the perspective of code refactoring, it is actually to divide and conquer a complex system, so that the logic of each part can be highly reused and highly scalable.

 

Principle of interceptor

The interceptor of the struts2 framework is dynamically configured. If you do not need to use an interceptor, you only need to cancel the application in the configuration file. You can configure an interceptor in the configuration file. Whether or not an interceptor is applied has no impact on the struts2 framework.

We can also extend the interceptor. This shows the pluggable feature of the interceptor.

 

Understanding dry (don't repeat yourself) Rules

When we develop software, we will encounter such a situation where the same code segment is required in multiple places, so we will "copy" and "Paste" to implement the function; if it comes to software efficiency or quality, it is unqualified. In terms of software maintenance, it will be disgusting.

 

The following images are better understood:

 

We usually choose to extract the code snippet to make it a public method for each module to call. However, if I want to change it now, I will not call the code snippet above, to call other codes, you must manually modify these three modules. If it is placed in the interceptor, the system will automatically call it at this time. The method is called by the system. You only need to configure it in the configuration file.

 

It can be seen that the interceptor can automatically call different methods, or even completely change the target method. The powerful decoupling function of the interceptor is very good here.

 

Instance

Configure the interceptor in the configuration file

<Packagename = "struts2" extends = "struts-Default">

<Interceptors>

<! -- Define the logging interceptor -->

<Interceptorname = "myloginterceptor" class = "com. bjpowernode. struts2.myloginterceptor"/>

<! -- Define the security interceptor -->

<Interceptorname = "mysecurityinterceptor" class = "com. bjpowernode. struts2.mysecurityinterceptor"/>

 

<! -- Interceptor Stack -->

<Interceptor-stackname = "myinterceptorstack">

<Interceptor-refname = "defaultstack"/>

<! -- Custom interceptor -->

<Interceptor-refname = "myloginterceptor"/>

<Interceptor-refname = "mysecurityinterceptor"/>

</Interceptor-stack>

 

</Interceptors>

<! -- Defined as the default interceptor, and all actions will be used -->

<Default-interceptor-refname = "myinterceptorstack"/>

<Actionname = "login" class = "com. bjpowernode. struts2.loginaction">

<Result>/login_success.jsp </result>

<Resultname = "error">/login_error.jsp </result>

</Action>

</Package>

 

Summary

It can be seen from the above that the interceptor is an important part of struts2, which makes the configuration of struts2 more flexible without affecting any operations of the Framework, and reflects the idea of high reuse and expansion. This is not an embodiment of object-oriented. It can be seen that the interceptor is cleverly designed. From this point on, we can also understand that when we encounter problems, we need to change, abstract, and encapsulate them so that the less code we write, the easier maintenance, and the higher efficiency.

[Learn struts2 step by step with me] -- interceptor