commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taras Tielkes <>
Subject RE: VOTE: Release 1.0 of Validator
Date Tue, 24 Sep 2002 08:44:03 GMT
Hi James,

Will expanded documentation be part of a release?

I'm currently trying to use commons-validator in a stand-alone program
(outside of Struts), but I'm having a hard time.

I know that there's always the source to read, but I wouldn't object to:

A DTD of XSD file defining the configuration format (yes, I know it's
simple, but it's good to specify things like these)

An explanation of how elements in the .xml configuration file map to members
of the runtime object model
-The mapping is absolutely nonintuitive (This is what I've figured out, I
may be wrong):
	a "validator" element -> an "action" at runtime?
	a "name" attrubute of a "msg" element -> is referred to as the "key"
Improve the general documentation. For instance: what are "Result Values"?
(from the getResultValueMap()).

But even more important is a explanation of why to use something. (When do
such "Result Values" come in handy?)
Some (commented) sample code describing the most commons scenarios:
-How do I reuse resources? Where do I put these and how do I refer to them?
-How to internationalize resources?
-How to write a new validator?
-And *why the hell* should I call validator.addResource("java.util.List",
myList) just to get some errors? I'd expect a "validation framework" to have
a more robust way of error reporting. Anyway, if there's a good reason for
this, document it.

General behaviour and flow of control.

I've written a couple of validators and connected these to a field using


Yet always, B is called first, and A is *always* called as well, no matter
what the outcome of B was. It may be that I got I bad nightly release, but
there no way to know by reading the documentation. Write down what the thing
is supposed to actually do.



> -----Original Message-----
> From: James Turner []
> Sent: Tuesday, September 24, 2002 9:39 AM
> To:
> Subject: VOTE: Release 1.0 of Validator
> Hi all,
>     Validator should have a release before packages likes Struts make 
> releases based on it.  Therefore I am proposing to do a 1.0 
> release on 1 
> November, and volunteering to release manage it.
>     There are at present very few bugs against Validator (6), 
> some of which 
> are either already closeable or could be fixed with little 
> effort.  However, I am about to release a near-complete 
> rewrite of the core 
> Validator methods (following the consensus of the previous 
> vote on that 
> matter), and want to give the new code some time to settle in 
> and be tested 
> before freeze.
>     The proposed schedule is:
> 1 October - Feature freeze for Validator 1.0
> 15 October - Code freeze for Validator 1.0
> 1 November - Final Release Build
> The current outstanding bugs to fix in Validator before release are:
> 7318  javascript: zero - means bad integer??
> 7349  Date Validation passes invalid date
> 8787  Indexed field validation patch
> 10584 Not all validation files are read in Validation PlugIn
> 10780  A few refactorings to
> 10782  If two fields are required, and one has a mask, the mask is
> Please vote as follows:
> +1: I'm in favor of a Validator 1.0 release according to the 
> schedule outlined
> 0: Like I care?
> -1: I have an objection either to the schedule, the release, 
> or the choice 
> of release manager (please specify)
> 3.1415926: I am an irrational person
> James
> --
> To unsubscribe, e-mail:   
For additional commands, e-mail:

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

View raw message