Taras, These are all excellent ideas. Would it be possible for you to submit a patch for one/all of these? You're input is very much welcomed and we would like to invite you to participate even more.
Thanks, Scott Sanders > -----Original Message----- > From: Taras Tielkes [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 24, 2002 1:44 AM > To: 'Jakarta Commons Developers List' > Subject: RE: VOTE: Release 1.0 of Validator > > > 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:commons-dev-> [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]>
