The main feature of the Convention plug-in is "convention is better than configuration ".
Action Search and ing conventions
To be able to use the Convention plug-in, you must install the Convention plug-in the struts 2 Application to copy the Struts2-convention-plugin.jar file to the WEB-INF/lib path of the struts 2 application.
For the Convention plug-in, it will process the actions of the following two Java classes:
1. All Java classes that implement COM. opensymphony. xwork2.action
2. All Java classes whose names end with actions
The Convention plug-in of struts 2 allows the following three constants to be set:
Constant |
Description |
Struts. Convention. Exclude. Packages |
Specifies the Java classes that do not scan those packages. the Java classes in these package structures are not automatically mapped to actions. |
Struts. Convention. Package. locators |
The Convention plug-in uses the package specified by this constant as the root package for searching action. For example, for the action. User. loginaction class, it should be mapped to/user/login according to the Conventions; If this constant is set to user, the action is mapped to/login. |
Struts. Convention. Action. Packages |
The Convention plug-in uses this constant to specify a package as the root package to search for Action classes. |
After an appropriate action class is found, the Convention plug-in will deploy these actions as agreed. When an action is deployed, the actions, action, struts, and struts2 packages are mapped to the root namespace, and the sub-packages under these packages are mapped to the corresponding namespace.For example:
Com. App. Action. Books. getbooks ing to/books
Com. App. Action. registaction ing/
Com. App. Action. Struts. Manage. User. useraction ing to/manage/user
Map the name attribute according to conventions
The name attribute of the action (that is, the URL to be processed by the Action). Based on the class name ing of the action, perform the following two steps to map the action name:
1. If the action class name contains the action suffix, remove the action Suffix of the action class name. Otherwise, no processing will be performed.
2. Write the action class name (uppercase letters for each word and lowercase letters for other subtitles) into a hyphen (lowercase letters, separated by a hyphen ).
For example:
Com. App. Action. loginaction ing to:/login. Action
Com. App. Action. User. loginaction ing to: User/login. Action
Com. App. Action. User. loginregistaction ing to: User/login-regist.action
For the action classCodeThere is still no need to make any changes.
Map result according to conventions
After processing user requests, action returns a string as the logical view, which must be mapped to the actual physical view. By default, Convention also serves as the ing between the logical view and the physical view.
By default, Convention always locates physical resources in the WEB-INF \ content path of the Web application. Therefore, the resource identification convention is: actionname + resultcode + suffix. If a logical view cannot find the corresponding view resource, convention automatically tries to use actionname + suffix as the physical view resource.
For example, assume that all the result types are dispatcher.
Action URL |
Name of the returned logical view |
Corresponding physical view |
/Login |
Success |
\ WEB-INF \ content \ login-success.jsp |
/User/login |
Success |
\ WEB-INF \ content \ User \ login-success.jsp |
/User/regist |
Error |
\ WEB-INF \ content \ User \ regist-error.jsp |
Conventions of the Action key
If you want to enter another action to form the action chain instead of the view page after processing an action. You only need to observe the following three conventions:
1. The logical view string returned by the first action does not have the corresponding view resource.
2. The second action and the first action are in the same package.
3. The third action ing URL is: firstactionname + resultcode
The following is an example:
After the first action processes the user request, it is forwarded to the second action for further processing. Then, the second action is taken to the view page and the corresponding information is printed.
First Action: firstactionjava
1 Public Class Firstaction Extends Actionsupport { 2 Private String tip1; 3 4 Public String gettip1 (){ 5 Return Tip1; 6 } 7 8 Public Void Settip1 (string tip1 ){ 9 This . Tip1 = Tip1; 10 } 11 12 Public String execute (){ 13 Settip1 ("First Action prompt" ); 14 Return "Second" ; 15 } 16 }
This action returns the "second" string after processing the user request. In order to enable this action to enter the second action after processing. For the returned string, the URL mapped to the second action should be: First-second.
Therefore, the second action class is named firstsecondaction.
The second action: firstsecondaction. jsp
1 Public Class Firstsecondaction Extends Actionsupport { 2 3 Private String tip2; 4 5 Public String gettip2 (){ 6 Return Tip2; 7 } 8 9 Public Void Settip2 (string tip2 ){ 10 This . Tip2 = Tip2; 11 } 12 13 Public String execute () Throws Exception { 14 Settip2 ("the second action prompt ...." ); 15 Return Success; 16 } 17 18 }
After firstaction processes user requests, the system automatically calls firstsecondaction to process user requests. Go to view resource.
the first JSP page: thefirst. after clicking the button in JSP, go to the first action to process the user request. This action = "first"
1 form action =" first " > 2 input type =" Submit " value =" click Next action " > 3 form >
The second JSP page: The second view resource. After the second action processes the user request, it is forwarded to the view resource. And print the corresponding information.
Because the result ing of the second actiond is: first-second-success. So the view Resource Name is: first-second-success.jsp
1$ {Tip1}<BR/>2$ {Tip2}<BR/>
The following page is displayed:
Read Li Gang's lightweight Java EE Enterprise Application Practice (Third edition)-Struts 2 + spring 3 + hibernate Integrated Development