myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cagatay Civici" <cagatay.civ...@gmail.com>
Subject Re: Client Validation Design Discussion
Date Wed, 12 Jul 2006 11:23:36 GMT
Hi,

Yes, using the validatorbase seems a better way in this case. Also as you
said, it would be better to remove the abstract signature since it'll break
other validators like in sandbox.

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?

Cagatay

On 7/12/06, Mario Ivankovits <mario@ops.co.at> wrote:
>
> Hi Cagatay!
> > There are two method getJsFunction() and getParams() that must be
> > implemented by extended validators so which design seem more convenient?
> >
> > * Using an IClientSideValidator which will be implemented by extended
> > validators marking them capable of doing validation at client side.
> >
> > or
> >
> > * Using ValidatorBase class which is the parent of all extended
> > validator and declare the two methods as abstract.
> >
> > I've chosen the abstract class instead of the validator although all
> > the design patterns books say favor composition over inheritance:)
> > Because the plan is to make all the extended validators capable of
> > client side.
> But the same books say that "instanceof" is a no-no, no? ;-)
>
> So I'll say lets add it to the ValidatorBase - but not as abstract
> methods, else you'll break any other validator out there using
> ValidatorBase as super class.
> And it is not a requirement to support the JS stuff.
>
> I think, this is not that bad a design and makes it very clear that the
> JS stuff is supported by tomahawk core.
>
> my 2ct
>
> Ciao,
> Mario
>
>

Mime
View raw message