The Struts User's Guide - Validator Guide User Guide Table of Contents Preface

The Struts User's Guide - Validator Guide User Guide Table of Contents Preface Introduction Model Components View Components Controller Components Configuration Release Notes Installation Developer Guides Bean Tags HTML Tags Logic Tags Nested Tags Tiles Tags Utilities Validator Quick Links Welcome User and Developer Guides * FAQs and HowTos Contributors David Winterfeldt James Turner Rob Leland Niall Pemberton Struts Validator Guide Struts Validator The Struts Validator, in some form, has been available since the days of Struts 0.5. It was orignally packaged as a developer contribution. Later, the core code was moved to the Jakarta Commons and a Struts specific extension became part of Struts since 1.1. For the convenience of the many developers who have been using the Struts Validator all along, this document first overviews the core functionality and then covers the changes and new functionality added since Struts 1.1. Once you have configured the Validator Plug-In, so that it can load your Validator Resources you just have to extend org.apache.struts.validator.action.ValidatorForm instead of org.apache.struts.action.ActionForm. Then when the validate method is called, the action's name attribute from the struts-config.xml is used to load the validations for the current form. So the form element's name attribute in the validator-rules.xml should match action element's name attribute. Another alternative is to use the action mapping you are currently on by extending the ValidatorActionForm instead of the ValidatorForm. The ValidatorActionForm uses the action element's path attribute from the struts-config.xml which should match the form element's name attribute in the validator-rules.xml. Then a separate action can be defined for each page in a multi-page form and the validation rules can be associated with the action and not a page number as in the example of a multi-page form in the validator example. Internationalization Validation rules for forms can be grouped under a FormSet element in the validator-rules.xml file. The FormSet has language, country, and variant attributes that correspond with the java.util.Locale class. If they are not used, the FormSet will be set to the default locale. A FormSet can also have constants associated with it. On the same level as a FormSet there can be a global element which can also have constants and have validator actions that perform validations. Note: You must declare a default FormSet without internationalization before your internationalized FormSets. This allows the Validator to fall back to the default version if no locale is found. The default error message for a pluggable validator can be overriden with the msg element. So instead of using the msg attribute for the mask validator to generate the error message the msg attribute from the field will be used if the name of the field's name attribute matches the validator's name attribute. The arguments for error messages can be set with the arg0-arg3 elements. If the arg0-arg3 elements' name attribute isn't set, it will become the default arg value for the different error messages constructed. If the name attribute is set, you can specify the argument for a specific pluggable validator and then this will be used for constructing the error message. <field property="lastName" depends="required,mask"> <msg name="mask" key="registrationForm.lastname.maskmsg"/> <arg0 key="registrationForm.lastname.displayname"/> <var> <var-name>mask</var-name> <var-value>^[a-zA-Z]*$</var-value> </var> </field> By default the arg0-arg3 elements will try to look up the key attribute in the message resources. If the resource attribute is set to false, it will pass in the value directly without retrieving the value from the message resources. Note that since Struts 1.1, you must explicitly define your message resource in any module that is going to use the Validator, due to a problem accessing the top-level resource. This only effects applications which are using modules. <field property="integer" depends="required,integer,intRange"> <arg0 key="typeForm.integer.displayname"/> <arg1 name="intRange" key="${var:min}" resource="false"/> <arg2 name="intRange" key="${var:max}" resource="false"/> <var> <var-name>min</var-name> <var-value>10</var-value> </var> <var> <var-name>max</var-name> <var-value>20</var-value> </var> </field> Standard Built In Validations Validator is shipped with the following set of pre-defined validation rules. required - mandatory field validation. Has no variables. <field property="name" depends="required"> <arg0 key="customer.name"/> </field> requiredif - field dependant validator Deprecated, use validwhen.validwhen - validator for checking one field against a nother. see later section titled Designing "Complex Validations with validwhen".minlengt h - validate input data isn't less than a specified minimum length. Requires a minlength variable. <field property="name" depends="required,minlength"> <arg0 key="customer.name"/> <arg1 name="minlength" key="${var:minlength}" resource="false"/> <var><var-name>minlength</var-name><var-value>3</var-value></var> </field> maxlength - validate input data doesn't exceed a specified maximum length. Requires a maxlength variable. <field property="name" depends="required,maxlength"> <arg0 key="customer.name"/> <arg1 name="maxlength" key="${var:maxlength}" resource="false"/> <var><var-name>maxlength</var-name><var-value>30</var-value></var> </field> mask - validate format according to a regular expression. Requires a mask variable to specify the regular expression. Since version 1.1, the regular expression must start with a ^ and end with a $ (see example below). <field property="name" depends="required,mask"> <msg name="mask" key="registrationForm.lastname.maskmsg"/> <arg0 key="registration.name"/> <var><var-name>mask</var-name><var-value>^[a-zA-Z]*$</var-value></var> </field> byte - validates that a field can be converted to a Byte. <field property="age" depends="byte"> <arg0 key="employee.age"/> </field> short - validates that a field can be converted to a Short. <field property="productnumber" depends="short"> <arg0 key="order.prodno"/> </field> integer - validates that a field can be converted to an Integer. <field property="ordernumber" depends="integer"> <arg0 key="order.number"/> </field> long - validates that a field can be converted to a Long. <field property="ordernumber" depends="long"> <arg0 key="order.number"/> </field> float - validates that a field can be converted to a Float. <field property="amount" depends="float"> <arg0 key="sale.amount"/> </field> double - validates that a field can be converted to a Double. <field property="amount" depends="double"> <arg0 key="sale.amount"/> </field> date - validates that a field can be converted to a Date. This validation rule uses java.text.SimpleDateFormat to parse the date and optionally either a datePattern or datePatternStrict variable can be used. If no pattern is specified the default short date format is assumed. The difference between using the datePatternStrict and datePattern variables is that datePatternStrict checks additionally that the input data is the same length as the pattern specified (so for example 1/1/2004 would fail with a pattern of MM/dd/yyyy). <field property="saledate" depends="required,date"> <arg0 key="myForm.saledate"/> <var><var-name>datePattern</var-name><var-value>MM/dd/yyyy</var-value></ var> </field> <field property="saledate" depends="required,date"> <arg0 key="sale.orderdate"/> <var><var-name>datePatternStrict</var-name><var-value>MM/dd/yyyy</var-va lue></var> </field> range - validate number range. Deprecated, use intRange, floatRange or doubleRange.intRange - validates that an integer field is within a specified range. Requires min and max variables to specify the range. This validator depends on the integer validator which must also be in the field's depends attribute. <field property="age" depends="required,integer,intRange"> <arg0 key="employee.age"/> <arg1 name="intRange" key="${var:min}" resource="false"/> <arg2 name="intRange" key="${var:max}" resource="false"/> <var><var-name>min</var-name><var-value>18</var-value></var> <var><var-name>max</var-name><var-value>65</var-value></var> </field> floatRange - validates that a float field is within a specified range Requires min and max variables to specify the range. This validator depends on the float validator which must also be in the field's depends attribute. <field property="ordervalue" depends="required,float,floatRange"> <arg0 key="order.value"/> <arg1 name="floatRange" key="${var:min}" resource="false"/> <arg2 name="floatRange" key="${var:max}" resource="false"/> <var><var-name>min</var-name><var-value>100</var-value></var> <var><var-name>max</var-name><var-value>4.99</var-value></var> </field> doubleRange - validates that a double field is within a specified range Requires min and max variables to specify the range. This validator depends on the double validator which must also be in the field's depends attribute. <field property="ordervalue" depends="required,double,doubleRange"> <arg0 key="employee.age"/> <arg1 name="doubleRange" key="${var:min}" resource="false"/> <arg2 name="doubleRange" key="${var:max}" resource="false"/> <var><var-name>min</var-name><var-value>100</var-value></var> <var><var-name>max</var-name><var-value>4.99</var-value></var> </field> creditCard - validate credit card number format <field property="name" depends="required, creditCard"> <arg0 key="customer.cardnumber"/> </field> email - validate email address format <field property="customeremail" depends="email"> <arg0 key="customer.email"/> </field> url - validates url format. Has four optional variables (allowallschemes, allow2slashes, nofragments and schemes) which can be used to configure this validator. allowallschemes specifies whether all schemes are allowed. Valid values are true or false (default is false). If this is set to true then the schemes variable is ignored. allow2slashes specifies whether double '/' characters are allowed. Valid values are true or false (default is false). nofragments specifies whether fragements are allowed. Valid values are true or false (default is false - i.e. fragments are allowed). schemes - use to specify a comma separated list of valid schemes. If not specified then the defaults are used which are http, https and ftp. <field property="custUrl" depends="url"> <arg0 key="customer.url"/> </field> <field property="custUrl" depends="url"> <arg0 key="customer.url"/> <var> <var-name>nofragments</var-name> <var-value>true</var-value> </var> <var> <var-name>schemes</var-name> <var-value>http,https,telnet,file</var-value> </var> </field> Constants/Variables Global constants can be inside the global tags and FormSet/Locale constants can be created in the formset tags. Constants are currently only replaced in the Field's property attribute, the Field's var element value attribute, the Field's msg element key attribute, and Field's arg0-arg3 element's key attribute. A Field's variables can also be substituted in the arg0-arg3 elements (ex: ${var:min}). The order of replacement is FormSet/Locale constants are replaced first, Global constants second, and for the arg elements variables are replaced last. <global> <constant> <constant-name>zip</constant-name> <constant-value>^\d{5}(-\d{4})?$</constant-value> </constant> </global> <field property="zip" depends="required,mask"> <arg0 key="registrationForm.zippostal.displayname"/> <var> <var-name>mask</var-name> <var-value>${zip}</var-value> </var> </field> The var element under a field can be used to store variables for use by a pluggable validator. These variables are available through the Field's getVar(String key) method. <field property="integer" depends="required,integer,intRange"> <arg0 key="typeForm.integer.displayname"/> <arg1 name="intRange" key="${var:min}" resource="false"/> <arg2 name="intRange" key="${var:max}" resource="false"/> <var> <var-name>min</var-name> <var-value>10</var-value> </var> <var> <var-name>max</var-name> <var-value>20</var-value> </var> </field> Designing Complex Validations with validwhen [Since Struts 1.2.0] A frequent requirement in validation design is to validate one field against another (for example, if you have asked the user to type in a password twice for confirmation, to make sure that the values uploads/Finance/ the-struts-user-x27-s-guide-validator-guide.pdf

• Détails
• Publié le Apv 28, 2022
• Catégorie Business / Finance
• Langue French
• Taille du fichier 0.0255MB