Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

A brief Analysis of Controller configuration in combination with actual combat

2025-01-21 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Network Security >

Share

Shulou(Shulou.com)06/01 Report--

1. Xwork.xml master file

Xwork.xml is the configuration file of WebWork itself, and it is the backbone of the configuration file in actual development.

Xwork defines a default package that contains xwork child files through include. As follows:

Back to the top.

2. Xwork.xml sub-file

On the one hand, xwork subfiles can effectively decompose large programs, which is in line with the modular segmentation of program development.

On the other hand, it helps us to traverse the whole program, which is helpful to the future operation and maintenance.

Because the structure definition of xwork.xml is consistent in the process of webwork development, it ensures a lower learning cost.

/ user/diruser.jsp doError.action / result.jsp / result.jsp

Back to the top.

2.1 package

Package: package, the name of the package can be understood as the name of the module (the names of each child package cannot be duplicated). All action are defined at the next level of the package.

Namespace: namespace, such as: namespace= "/ user", describes the path of the sub-module jsp file and specifies the url URL: / user/*.action when requesting access.

If the namespace is empty, the url URL when the request is made: / * .action.

Benefits of namespaces:

1) embody modularization

2) if the namespace is empty, the url URLs of the access request are all / * .action, which is easy to conflict.

Back to the top.

2.2 action

Action name: the name of the corresponding request, such as dirUser,url:/user/dirUser.action

Action class:com.rambo.app.base.user.action.DirUser backend receives the java processing class corresponding to the request

Action.result.location:diruser.jsp displays the processing results, and the directory location of the file is / user/diruser.jsp

Back to the top.

2.3 result

ServletDispatcher is the core of WebWork framework mechanism. It and Action play the role of controller in MVC mode, and MVC mode realizes the separation of model and view through controller.

The Result in the Xwork file is a string constant returned by Action after execution, which indicates the completion status of Action execution, such as successful execution, failed execution, and so on.

WebWork's Action provides several default ones (including success, error, login, none, input, etc.). In addition, Result can be defined by itself, as long as it is a string constant.

Name is the returned string constant value in the Result tag definition, such as: name= "success" indicates

If the Action is executed successfully, the returned result will be output according to the specific configuration of this tag.

Type corresponds to the Result Type class. After the Action execution is completed and the Result is returned, it decides which view technology to use and presents the execution result to the user, mainly including:

Parameter type describes dispatcher

Location (required)

Parse

Dispatched to the jsp page display, where the Action request corresponds to the

The data can be used directly by the page

Redirectlocation (required)

Parse

Redirects the response to the location specified by the browser, which will cause the Action execution to complete

Is missing or no longer available. Directs the response to the new url specified by the parameter location

Chain

ActionName (required)

Namespace

Action Chaining: a special view result that links to another Action after execution

Continue execution in Action. The new Action uses the context of the previous Action (ActionContext)

1. Type = dispatcher userinfo.jsp abbreviation: userinfo.jsp 2. Type = redirect.. / userinfo.jsp abbreviation:.. / userinfo.jsp3. Type = chain ramboAction:...

Back to the top.

2.4 interceptor

WebWork intercepts the Action request and invokes the interceptor method before or after the Action execution. In this way, the function can be injected into the Action by plug and unplug.

The most commonly used interceptors in actual development mainly encapsulate the processing of form parameter submission, such as objectification, including the following three categories:

1) default interceptor

2) support model-driven interceptor

3) support file upload interceptor

Back to the top.

2.4.1 defaultStack default interceptor

The default form processing interceptor. As long as the Action defined by Xwork.xml inherits the ActionSupport class, the jsp form data can be automatically converted into the corresponding variables defined by the java file through the default interceptor.

Note: the name name in the jsp file form input corresponds to the variable name in the java file.

Such as the sysId and gUser objects in the following example.

Front end:

User name: password:

Xwork.xml:

User/dirUser.action doError.action

Java side:

Public class LoginAction extends ActionSupport {private Integer sysId; public GUser gUser = new GUser (); public LoginAction () {} public String execute () {/ / business processing. Return Action.SUCCESS;} / / getter/setter.}

Back to the top.

2.4.2 modelStack model-driven interceptor

The Action defined by Xwork.xml needs to implement the Object getModel () method in the ModelDriven (model driven) interface while inheriting the ActionSupport class, which returns the model object to be received.

You can directly convert the jsp form data into the corresponding objects defined by the java file.

Such as the info object in the following Java example. Note: the name in the jsp file form input should correspond to the attributes in the User class corresponding to the info object in the java file.

Front end:

Email: name: Tel:

Xwork.xml:

.. / resultjson.jsp.. / resultjson.jsp

Java side:

Public class EditUserInfo extends ActionSupport implements ModelDriven {private GUser info = new GUser (); public Object getModel () {return info;} public EditUserInfo () {} protected String execute () {/ / business processing. Return Action.SUCCESS;} / / getter/setter.}

Back to the top.

2.4.3 uploadStack upload interceptor

The Action defined by Xwork.xml needs to inherit the ActionSupport class. Through the file upload interceptor, you can automatically convert the jsp form data and the number of binary files into the corresponding variables defined by the java file, such as the userId and uploadFile objects in the following example.

Note: the name name in the jsp file form input corresponds to the variable name in the java file.

Front end:

Upload attachment:

Xwork.xml:

.. / resultxml.jsp.. / resultxml.jsp

Java side:

Public class UploadUserImg extends ActionSupport {private Integer userId; private File uploadFile; public UploadUserImg () {} public String execute () {if (uploadFile = = null | | userId = = null) return Action.ERROR; / / business processing. Return Action.SUCCESS;} / / getter/setter.}

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Network Security

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report