On 4/19/06, Hubert Rabago <[EMAIL PROTECTED]> wrote: > Sure there are problems. > > > -----Original Message----- > > From: Adam Winer [mailto:[EMAIL PROTECTED] > > > > The Shale incorporation of commons-validator is not a good > > role model... > > > > First off, you can turn on client-side validation without > > turning on server-side > > validation, which is completely wrong. > > I'm not sure why Craig did it this way as well, but he did say this > could change before he marks the API as final. > > > > Also, it lumps all of the functionality into one tag with a "type" > > parameter, which is an API design that has usability problems. > > The biggest advantage of this is that one can easily add custom > validations without having to declare a new TLD and registering a new > validator in faces-config. Just provide a javascript method and a > server side method. I think this is a big convenience.
And what if your custom validator needs an attribute other than those specified in that one tag? That's a no go. It'd be OK to have a convenience tag - like <f:validator> - 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. -- Adam > > And implementation-wise, it uses popups. (At some point, Struts > > validator used a separate popup for every message instead > > of one popup for all, which is really annoying - dunno if that's > > been fixed since then.) > > Niall Permberton (Commons Validator developer) has a Javascript > extension [1] that fixes this. I've been able to build on this to > show validation error messages on the page for Struts, and I've been > able to use it to do the same for JSF as well (or at least, prove that > it works). I'm at the same point as Cagatay, where I want to use the > same message tag that the server side validation will use so no matter > which side does validation, the message will appear on the same place. > > At this point, though, your stack becomes Shale + Commons Validator + > Niall's JS extension + my integration code. However I feel it's still > better than server side validation for required, though. > > Hubert > > [1] http://niallp.pwp.blueyonder.co.uk/validatorjs.html > > > > On 4/18/06, Cagatay Civici <[EMAIL PROTECTED]> wrote: > > > Shale comes with it's own validators that can do both client side and > > > server > > > side. Each validator has flags like client="true" server="true". The > > > disadvantage is that client side validation uses popus that is not favored > > > much. > > > > > > A central mechanism to control validation setting should be good but also > > > it > > > would be flexible if a validator can override the global setting. > > > > > > > > > On 4/19/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > > > And you might check what Struts Shale already does. From what I know > > > > it integrates commons-validator. >
