On Thu, 11 Jul 2002 [EMAIL PROTECTED] wrote:
> Date: Thu, 11 Jul 2002 13:10:16 -0400
> From: [EMAIL PROTECTED]
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Why not have tags specify simple field validation?
>
> One of the key uses of ActionForm classes is to do field validation.
> Often, this validation is simple data-type checking, or verifying that
> fields are non-null.
>
> It seems like 80% of the validation tasks could be done by adding one or
> two simple optional parameters to form tags. This would allow the view
> to be more completely located in the JSPs, rather than have some
> presentation code be in the JSP and other presentation issues -- the
> validation -- be in the ActionForm. Putting as much of the view as
> possible in the JSP would more effectively separate developer roles, be
> better coupling, etc.
>
> Form tags could have simple optional parameters that do things like:
> o Specify that a tag value be non-null
> o Specify the field's "validation data type"
>
> Data type validators could be specified in the configuation file, in the
> tag handling code, or in special Java classes. The tags might look
> something like:
>
> <html:text name="employee" property="snn" datatype="SSN"
> nullsallowed="false"/>
>
> This would specify that this field be validated under the "SSN" set of
> rules. In this case, the validation rules could check for the
> 999-99-9999 format. If validation fails, the error would be stored and
> displayed as usual.
>
> You would only need a small library of such data type validation rules
> to cover most situations. For more sophisticated validation the
> programmer is free to code the "validate" routine in an ActionForm.
>
You probably want to take a look at the Validator Framework (standard
part of Struts 1.1, separately available for 1.0), which extends
this idea to a complete library of validations that you can declaratively
add to your forms, complete with the optional generation of client side
JavaScript to enforce the constraint on the client side if possible.
One difference from what you are suggesting is that the constraints are
declared in an external configuration file, rather than being embedded in
the page itself. This fits my personal view of where the appropriate
separation of roles should be -- the business rules that are expressed in
validation constraints, ultimately, come from the model tier and not the
presentation tier, so they should be defined by those same folks.
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
