commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun Thomas" <Arun.Tho...@solidusnetworks.com>
Subject jakarta-commons/validator General Question
Date Mon, 19 May 2003 17:22:20 GMT
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


Mime
View raw message