Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
From: "Matthias Wessendorf" <mailings@matthias-wessendorf.de>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
Subject: RE: [validator] Why doesn't commons-validator include functional
 validators?
Date: Fri, 21 May 2004 22:57:20 +0200
Message-ID: <001c01c43f76$35dccc50$6402a8c0@fumakilla>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <40AE6880.90300@twdata.org>
Importance: Normal

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