[jira] Closed: (STR-2281) Add 'validation' attribute to ActionMappings to control which validation to perform

["Paul Benedict (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/struts/browse/STR-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Benedict closed STR-2281.
------------------------------

    Resolution: Won't Fix
      Assignee:     (was: Struts Developers)

> Add 'validation' attribute to ActionMappings to control which validation to perform
> -----------------------------------------------------------------------------------
>
>                 Key: STR-2281
>                 URL: https://issues.apache.org/struts/browse/STR-2281
>             Project: Struts 1
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.2.4
>         Environment: Operating System: All
> Platform: All
>            Reporter: William Ferguson
>            Priority: Minor
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.