I suppose there's no reason you can't have both. Specific tags for built-in validators, and a generic one that can work with either built-in or user-supplied validators.
What I like about Niall's JS extension is that it allows the user to "override" the JS handling. For instance, if I wanted error messages *and* graphic indicators like in [1], I could have it without the JS framework getting in the way. A customizable JS framework, easy-to-use tags for built-in validators, and an ability to use my own custom validations without having to write custom tags (even if I had my own attributes). I wouldn't mind that. Hubert [1] http://www.themaninblue.com/writing/perspective/2005/10/05/form/form4.htm On 4/19/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > >From: "Hubert Rabago" <[EMAIL PROTECTED]> > > > > > On 4/19/06, Gary VanMatre wrote: > > > > It'd be OK to have a convenience tag - like - for > > > > using a new custom commons-validator, without any attributes at all > > > > other than "type". There's no good reason to cram all the pre-existing > > > > validators into one tag. They should be in separate tags. > > > > > > That's not a bad idea. > > > > I'm not sure about this, but doesn't this describe the existing > > Tomahawk validators (creditCard, email, regExp)? > > > > > That's what I was thinking too. We could create a subclass of > CommonsValidator or a custom tag for each type of validator. > Each subclass would only describe the attributes/variables needed > for the specific rule. > > I do like your ValidatorVar tag too because it is closer to the > commons validator way. It's like the f:attribute is to the component. > > > > Hubert > > > Gary >
