[validator] Validator/forms theory (was RE: Why doesn't commons-validator include functional validators?)

[Don Brown <mr...@twdata.org>]

Very interesting, particularly the weblog posting.  Cocoon's CForms 
takes the same approach of defining validation as part of the "form 
definition file", and many people are tying validation closer to the 
model/form by using XDoclet tags.  Another good discussion of CForms, in 
this case being compared against XForm-style XMLForms, is here: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105881304808076&w=2

To take what John is proposing to heart, the design goal of 
commons-validator to be easily embedded into a container is all the more 
important, if one wants to integrate validation with a 
container-specified form definition.  In the case of Struts, one single 
form definition might create a DynaActionForm and the commons-validator 
configuration to validate the fields. 

Don

Matthias Wessendorf wrote:

>Don,
>
>(perhaps abit OT)
>do you know this article?
>http://weblogs.java.net/pub/wlg/618
>
>and the JSR 94 (Java Rule Engine)
>http://www.jcp.org/en/jsr/detail?id=94
>
>perhaps you will find something usefull.
>
>Cheers,
>Matze
>
>
>  
>
>>-----Original Message-----
>>From: Don Brown [mailto:mrdon@twdata.org] 
>>Sent: Friday, May 21, 2004 10:37 PM
>>To: Jakarta Commons Developers List
>>Subject: [validator] Why doesn't commons-validator include 
>>functional validators?
>>
>>
>>After looking through the different validator usages - 
>>Struts, Spring, 
>>and the unit tests - I'm a bit confused why commons-validator doesn't 
>>ship with functional validators that can be used directly and 
>>not hidden 
>>by some adapter.  commons-validator contains validator 
>>classes, yes, but 
>>you still need to create a validator adapter class that 
>>accepts at least 
>>the bean and the Field object to interact with the validator.  
>>Furthermore, this adapter class (Struts and Spring both call it 
>>CheckFields) contains framework specific references, usually dealing 
>>with their errors system.
>>
>>The problem with this approach is it requires huge levels of 
>>duplication 
>>as each container needs to write their own adapter and error creation 
>>code.  I'm particularly confused because it seems the 
>>solution already 
>>exists within commons-validator - ValidationResult(s).  I 
>>would think a 
>>better approach would be for commons-validator to provide 
>>adapters for 
>>every validator to extract the field information from Field 
>>and pass it 
>>along to the actual validator.  The process of creating 
>>messages should 
>>be left to the class that called validator.validate() to process 
>>ValidationResults and handle the errors in a container-specific way.  
>>This way, new containers that want to use commons-validator 
>>don't have 
>>to write their own monolithic adapter class but can use validators as 
>>they are.  If commons-validator wants to separate a validator into a 
>>commons-validator adapter class and a actual  validation 
>>class, that is 
>>fine, but there really isn't any need for that adapter to depend on a 
>>container.
>>
>>If my premise is sound and the solution agreeable, I would be 
>>willing to 
>>do the leg work of writing container-independent adapters for each of 
>>the validators.
>>
>>Don
>>
>>---------------------------------------------------------------------
>>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
>
>  
>


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