STRUTS2 Data Input Checksum (1)--function verification

The rationale for using the STRUTS2 tag Library to achieve the above objectives:

The error messages are grouped into the field and action levels and are predefined in the Actionsupport class, and the difference is that

Fielderror is implemented by a map that actually records the name and error information of the field, so it can be displayed in the corresponding field on the page;

And Actionerror is through a collection implementation, there is no record of the source of the error, only the wrong message recorded.

Note that the following is a brief process:

(1) After the page is committed to the action, first struts attempts to type match and convert the input string information according to the type of property defined in the action, and if the input is null, it will place the content as the default value (0, 0.0, empty string, and so on) for the data Format mismatch, such as typing letters in the age column, and so on, struts will automatically prompt the default error, and return to input, this work is struts2 automatically completed.

(2) Then, the validation mechanism is in effect, calling the Validate () function and the validation logic in the XML Validation framework ("STRUTS2 Data input checksum (2)--xml verification"), and checking for Addfielderror () and Addactionerror (). Before the page is submitted, struts invokes the HasErrors () method of the Actionsupport (Strictly Validationaware Interface), which is simple, is to check whether the Fielderror map and Actionerror collection are empty, and if they are null, invoke the Execute () method [*] to schedule the business logic, otherwise return the error.

(3) Finally, the program performs forward operations based on the return information, and Struts.xml defines the jump logic for these return values.

If an error returns, the error message is prompted on the page

All Addfielderror () set information in the action will be displayed in the corresponding field position;

All Addactionerror () set information in the action will not be displayed unless the S:actionerror control is defined on the page, and the error will be displayed in UL format.

Support for multiple validation and jump logic

Struts also provides support for some action if it needs to be reused.

at [*] above, you can also specify any other name, which requires modifying the method attribute of the corresponding action in Struts.xml

<action name= "xxxaction" class= "com.myspace.myname.XXXAction" method= "Newexcutename" 

>
      

<result>success.jsp</result>
</action>

At the same time, we need to define a method in Xxxaction

Public String Newexcutename () {/*dummy code*/}

If you also define a

public void Validatenewexcutename () {/* Dummy code */}

Then before executing validate (), the program executes the Validatenewexcutename () method first

Consider putting all the common validation logic into the Validate () method

The above process is entirely dependent on the Java reflection mechanism, the efficiency will be lower, so unless it is really necessary, otherwise.

Localization of error hint strings

It is convenient to write error messages directly in the validator method, but it is not a good habit and cannot support localization. Here's a brief description of two ways to localize

1, Global internationalization default error prompts, first in the struts.xml to add a constant

<struts>
<constant name="struts.custom.i18n.resources" value="message"></constant>
</struts>

Then write the message.properties in the position with the Struts.xml sibling

XWORK.DEFAULT.INVALID.FIELDVALUE={0} Error

2. Validation error prompt for an action

Create a property file with the same name as the action in the Xxxaction sibling directory

Write in Xxxaction.properties

Invalid.fieldvalue. Field name = Error message