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 <[EMAIL PROTECTED]> 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
