commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <dgraham1...@hotmail.com>
Subject RE: jakarta-commons/validator General Question
Date Mon, 19 May 2003 18:34:44 GMT
You can call the static methods in GenericValidator directly.

The reason it's called "field validations" is because you're applying a 
specific set of validations to a field.  So, you can validate an entire bean 
by defining the validations to be passed by its individual properties.  The 
framework allows you to pass in the whole bean to be validated instead of 
requiring you to pass in each field.

I agree with you that validator should be bean focused and not field focused 
but even this requires you to define validations per property.

David


>Hmmm....
>
>On rereading, it appears my comment was not only wordy, but unclear. :]  My 
>comments about field vs. bean were actually focused on naming rather than 
>functionality and were meant in the following way:
>
>The use of the name "field validation" semantically suggests that 
>validations must be applicable to a specific field, and must always be 
>traceable to validation of a specific field.  However, the validator 
>framework does not enforce this semantic constraint in any way.  The 
>framework provides as arguments to the validation function an object with 
>fields, and additional variables/parameters for the validation to be 
>performed (currently encapsulated in the "field" object).  It then captures 
>and returns the result to the caller.
>
>As of the last release, commons validator doesn't actually directly provide 
>ANY validation functions - there's nothing present which can be called 
>directly from the validator framework.  Looking at struts, it seems clear 
>that all the validation functions currently available (in FieldChecks) are, 
>in fact, traceable to a particular field.  However, there doesn't seem to 
>be any reason to constrain this so tightly.  In a possible alternative 
>naming, "bean validations" could validate either specific fields of a bean 
>(form) separately from other fields, or they could validate any number of 
>fields in the context of other fields or validation parameters.  Obviously, 
>this behavious is available today (requiredif is a simple example), but the 
>naming is misleading.
>
>Does this help to clarify my previous comment?
>
>P.S. Your comment (the first paragraph) about using more generic terms 
>makes sense to me.  However, I still feel that using "property validation" 
>instead of "bean validation" would be misleading, as the framework does not 
>programmatically restict validations to properties.
>
>-----Original Message-----
>From: David Graham [mailto:dgraham1980@hotmail.com]
>Sent: Monday, May 19, 2003 10:36 AM
>To: commons-dev@jakarta.apache.org
>Subject: Re: jakarta-commons/validator General Question
>
>
>There is plenty of room for improvement in commons-validator.  The original
>author no longer maintains it so we've had to build up knowledge as we go.
>I agree that the symantics of the dtd should not use terms like "field" and
>"form".  More general terms like "property" and "bean" would be more
>appropriate.
>
>I don't understand your criticism of the field based validations.  It makes
>sense to me to define a form (or bean) with various fields (or properties)
>and be able to validate each property against a set of validations.  The
>bean can be used to validate properties together like the requiredif
>validation.
>
>David
>
>
> >Question/Comment for all those working on the commons validator
> >framework
> >out there.  I know that validator is primarily used by the struts
> >community, but I also know that the goal of moving it to the commons was 
>to
> >potentially make it available for use in a non-struts non-web specific
> >manner.  With that in mind....
> >
> >I've downloaded and modified a copy of the framework to work with a
> >Swing
> >GUI, and, in the process noticed a couple of things (I've submitted some
> >bugs for some of them).
> >
> >1) Why focus on "field" rather than "bean" validation?
> >
> >I'd like to ask whether there's a reason that the validator continues
> >to
> >focus on "field" validation.  Looking at most of the framework, as well 
>as
> >at the use of that framework in struts, it appears clear to me that the
> >entire bean is always the focus of the validation.  Many different
> >validations are applicable to a specific bean, and, in most cases, any
> >particular validation of the bean tends to focus on validation of one
> >specific property (field), but the argument to the validation function
> >provided by the framework is the entire bean.  In fact, the "requiredIf"
> >validator used by struts depends on exactly this fact - that particular
> >validator depends on the availability of the bean entire to validate some
> >properties depending on the values of other properties.
> >
> >Indeed, this sort of approach seems to me to be entirely reasonable and
> >much more useful, practically speaking, than attempting to force 
>validation
> >of only specific fields.  Is there a reason, therefore, to keep focusing 
>on
> >field validation rather than bean validation?  Perhaps I'm missing
> >something?  If not, wouldn't it be a good idea to consider transforming 
>the
> >dtd and the terminology in the documentation to identify what is actually
> >happening, rather than continuing to use the "field" terminology?
> >Obviously, this would be a change that would need to be worked in over
> >several releases, with deprecation of the old element (field) and 
>backward
> >compatibility of the new element (whatever it may be called (validation?) 
>+
> >whatever additional work is required to make sure what's available today
> >continues to function, but still....
> >
> >2) Why not incorporate validation method signature - the requirement
> >for
> >Object and Field - explictily into the framework?
> >
> >On another note, another item I've noticed is that the method arguments
> >found in the validation xml for describing the validation functions tend 
>to
> >be very similar - there's always an Object, a Field, and, in the case of
> >struts, some additional other items.  In almost every case, only the 
>Object
> >and Field are used for the validation itself (indeed, the object and 
>field
> >parameters are REQUIRED for the validator framework to function).  The
> >other elements are present to allow each validation method to 
>customizably
> >handle the results of the validation.  First of all, the commonality
> >between method arguments would suggest to me something else that would be
> >well encapsulated into the validation framework - why force everyone to
> >specify all these parameters everytime when it's clear that they will be
> >required?  Second, (and I've submitted a potential patch/suggestion for
> >this already) it seems that handling of the results is something that is
> >better done either through a callback with a standardized interface - in
> >this case, the best choice seems to be to provide a customizable
> >ValidatorResults prior to calling the Validator.validate().
> >
> >What do y'all think?
> >
> >-AMT
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>_________________________________________________________________
>Help STOP SPAM with the new MSN 8 and get 2 months FREE*
>http://join.msn.com/?page=features/junkmail
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message