DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39121>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39121


[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




------- Additional Comments From [EMAIL PROTECTED]  2006-04-18 03:25 -------
The current implementation is dependent on version 1.3 of commons validator. 
Some new conventions have been adopted for registering a validation rule in 
the validator's XML configuration file. In the action framework, validation 
was suited for declaring rules associated with a form. This worked well since 
generally a single action had the responsibility of handling all the posted 
form data at once.

However, JSF takes a component based approach. Each component has the 
responsibility of managing its posted data and rendering its state. In the 
component based world, it is easier to associated configuration values at that 
level versus what works best for struts action.

In an effort to reuse as much of commons validator and provide a method of 
registering new rules, a new convention was adopted for declaring validation 
rules. 

    <global>
      <validator name="mask"
                classname="org.apache.commons.validator.GenericValidator"
                method="matchRegexp"
                methodParams="java.lang.String,java.lang.String"
                msg="errors.invalid"
                jsFunctionName="validateMask"
                
jsFunction="org.apache.commons.validator.javascript.validateMask"           
                depends=""/>
    </global>
The rules declaration is the same but an added form is required to capture 
extra configuration information. The form is associated with the validation 
rule using a naming convention. The prefix of the form name 
is "org.apache.shale.validator.XXXX" where "XXXX" is the validation rule name.

   <formset>
     <form name="org.apache.shale.validator.mask">
The form is followed by a field and the property attribute of the form has the 
same value as the rule name.

           <field property="mask">

Within the field definition, arg's are used to define the parameters in order 
for message substitution and method argument value resolution.
There are two reserved name values for the arg node used to define messages 
and parameters.

               <arg position="0" name="message" key="arg" resource="false"/>
               <arg position="1" name="message" key="mask" resource="false"/>
               <arg position="2" name="message" key="submittedValue" 
resource="false"/>
               
               <arg position="0" name="parameter" key="submittedValue" 
resource="false"/>  
               <arg position="1" name="parameter" key="mask" 
resource="false"/> 
The "message" name arguments defines the possible MessageFormat parameter 
substitution where the "position" corresponds to the substitution parameter.

    errors.invalid={0} is invalid.

The "parameter" arguments define the variable names that hold values for the 
target validatior method identified by the validator rule name. The comma 
delimited class types in the "methodParms" value list correspond to the 
parameters by position.
  
  methodParams="java.lang.String,java.lang.String"
 
The var node is also used to explicitly define a JavaScript variable type. If 
not defined, the default is "string". The var-value is ignored because its 
captured by the shale commons validator instance.

               <var>
                   <var-name>mask</var-name>
                  <var-value></var-value>
                  <var-jstype>regexp</var-jstype>
               </var> 


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to