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=32217>.
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=32217

Add 'validation' attribute to ActionMappings to control which validation to 
perform

           Summary: Add 'validation' attribute to ActionMappings to control
                    which validation to perform
           Product: Struts
           Version: 1.2.4
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Validator Framework
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


Currently, validation is defined by specifying a true/false value for the
'validate' attribute for an ActionMapping, and which validation to perform is
defined by either the ActionMapping's (Form) 'name' or 'path' attribute
depending on whether the Form extends from ValidatorActionForm or not.

It seems to me that it would be clearer to introduce a 'validation' attribute
into ActionMapping which defines the Id of the validation (if any) to perform.
This would supercede the 'validate' attribute and removes the responsibility of
identifying the validation target from the combination of the (Form) 'name'
attribute and the ActionForm inheritance hierarchy.

It allows all the benefits of (currently) using a ValidatorActionForm to
validate based on ActionMapping path, plus those of using Form named mappings,
while also allowing the freedom to mix, match and reuse validations across
ActionMappings.

It should be easy to make this new addition entirely backward compatible. Ie If
'validation' attribute is not found then look for current attributes and follow
the existing validation path, at least for some deprecation period.

Once this refactoring has been achieved, it also opens up the possibility of
further enhancing the existing validation mechanism. Ie Allowing validations to
contain other validations etc. Though I would first start by simplifying the
validation definitions, which I also find somewhat non-intuitive at times.

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

Reply via email to