it's critical to make the real API an interface in this case. We can't
require that everyone on the planet extend from ValidatorBase if
they want to take part in this. For one example, what if I download
a third-party validator, and want to add client-side validation support to it?
So, +1 for an interface.
I'd also be -1 against being able to set it on an individual validator
level; wait 'til someone says it is necessary, and justifies that
need.
Regarding the name of an interface - does MyFaces have a standard
to preface interfaces with a capital I? JSF doesn't do that in the
standard, nor does much of anything I know of in J2EE. I'd be -1
on using a capital I prefix.
FWIW, it would be nice to also look at the Trinidad ClientValidator API;
here's a link to the Javadoc of the ADF version of that:
http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/apidocs/oracle/adf/view/faces/validator/ClientValidator.html
Also, recognize that client-side validation is only half of the picture; you
also need client-side converters. Trinidad has an API for that too:
http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/apidocs/oracle/adf/view/faces/convert/ClientConverter.html
-- Adam
On 7/12/06,
Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi Cagatay!
> One more discussion topic, the client validation is turned on/off via
> a context parameter, org.apache.myfaces.ENABLE_CLIENT_VALIDATION,
> Do you think validators should override this global setting via an
> attribute like client?
client=true|false - yes, I think this will be a nice feature to have.
Not that I really think that this will be widely used, but currently you
are "knee deep" ;-) in the validator stuff, so lets add it to
ValidatorBase too - and who knows what the users wanted to have later.
Ciao,
Mario
