Antonio Sánchez created WW-4340:
-----------------------------------

             Summary: Grouping same type validators
                 Key: WW-4340
                 URL: https://issues.apache.org/jira/browse/WW-4340
             Project: Struts 2
          Issue Type: Improvement
          Components: XML Validators
            Reporter: Antonio Sánchez
            Priority: Minor


In a middle sized application there may be hundreds of required fields, and 
maybe dozens of some other validator type, which are all very verbose to define.

For instance: guess a big form with many required fields:

    <validator type="requiredstring">
        <param name="fieldname">person.firstName</param>
        <message>First name is required.</message>
    </validator>
    <validator type="requiredstring">
        <param name="fieldname">person.lastName</param>
        <message>Last name is required.</message>
    </validator>
    ... same for age...
    ... same for manymor...

This is repeating the same pattern for both defining the validator and the 
corresponding message.

It would be great to have an abbreviated syntax, for instance (pseudo-language):

    <validator type="requiredstring">
        <param name="fieldname">person.lastName, person.lastName, person.age, 
person.manymore</param>
        <message>[MATCHED_FIELDNAME] is required.</message>
    </validator>

or

    <validator type="requiredstring">
        <param name="fieldname">person.lastName, person.lastName, person.age, 
person.manymore</param>
        <message key="requiredField" />
    </validator>

and 'global_validation_messages.properties' having

    requiredField = [MATCHED_FIELDNAME] is required. 

Not only "required" validator, but any other one. 

Advantages: 

1. Message is defined once. It is easy to uniformly change 'Field is required' 
to 'Please, fill this field".

2. Define affected fields all in a row. If my form has 10 required field, then 
10 validation definitions are currently needed. With this improvement, only 1 
definition is needed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to