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:
1)
A DTD of XSD file defining the configuration format (yes, I know it's
simple, but it's good to specify things like these)
2)
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"
3)
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.
4)
General behaviour and flow of control.
I've written a couple of validators and connected these to a field using
depends="validateA,validateB"
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.
Regards,
tt
> -----Original Message-----
> From: James Turner [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 24, 2002 9:39 AM
> To: [EMAIL PROTECTED]
> 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 Validator.java
> 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:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
