>From: "Adam Winer" <[EMAIL PROTECTED]>
>
> 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.
> >
>
> 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.
> >
I don't think it was Craig that contributed the shale commons validator.
> >
> > > Also, it lumps all of the functionality into one tag with a "type"
> > > parameter, which is an API design that has usability problems.
> >
I think the focus of this component was showing integration of JSF validator
with commons validator. A way to leverage and reuse an existing apache
library.
In implementation, the commons validator it doesn't jive with the JSF way
of doing things. It's designed to declare metadata outside of the component
and it's very much form centric versus component centric.
> > 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.
>
That's is no longer true. There is a nested JSP tag to add a "var" to the
the outer validator tag "s:validatorVar". The var's are no longer positional
but are added by name.
The validator client side _javascript_ now works in a UIData component too.
Introducing another issue..
> It'd be OK to have a convenience tag - like
> 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
>
Gary
>
> > > 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.
> > > >
> > > >
> > & gt; > 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.
> >
