commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <>
Subject Re: jakarta-commons/validator General Question
Date Mon, 19 May 2003 17:35:30 GMT
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 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?
>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:

View raw message