commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun Thomas" <>
Subject RE: jakarta-commons/validator General Question
Date Mon, 19 May 2003 18:14:12 GMT

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 [] 
Sent: Monday, May 19, 2003 10:36 AM
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 

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 


>Question/Comment for all those working on the commons validator 
>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 
>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 
>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 
>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?
>To unsubscribe, e-mail:
>For additional commands, e-mail:

Help STOP SPAM with the new MSN 8 and get 2 months FREE*

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message