Hi!
> 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 dont think this is the best use-case as you still have to change the
original validator code (implement the interface).
No, you just need to subclass it to implement the
interface, and override the validator class using
faces-config.xml.
To achieve this
without the need to change the source - so to add a client validator to
a validator you dont have the source or cant change it, it might be nice
to have a pluggable thingy.
Everyone brews its own soup here, as we can see ... but ok, I wont
complain about a interface as it allows a better flexibility if we think
we should provide a framework for others too.
> 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.
What do you mean by this? Do you mean we should NOT check if a validator
implements this interface but simply assume its implements (even empty)
on ValidatorBase?
No, I mean that you should check if a validator implements the interface. But we shouldn't add client="true|false" to MyFaces validators unless it's proven that this is useful.
> Also, recognize that client-side validation is only half of the
> picture; you
> also need client-side converters.
Lets do this once needed. In fact, I hope Trinidad become a more
integral part of MyFaces so that we can use Tomahawk and Trinidad and
... together :-)
How can you not need it? Verifying that dates are correctly formatted is really important, for example, and that's in converter land. I'd even go out on a limb and say that client converters are *more* important than client validators.
-- Adam
