Client Validation Design Discussion

[Cagatay Civici <ca...@gmail.com>]

Hi,

I'm about to finish my work on the client validation and have faced with a
design dilemma here.

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.

As a reminder of the issue;

http://www.irian.at/cagatay-validation-sandbox/home.jsf

Regards,

Cagatay

Re: Client Validation Design Discussion

[Cosma Colanicchia <co...@gmail.com>]

It seems to me that both ways lead to inheritance :)

I think that an interface should be used, especially if the *only*
goal of an abstract base class would be defining those two abstract
methods.

This is also more flexible because multiple interfaces inheritance is
allowed: suppose you have a validator which already extends some
class, you port it into Tomahawk and you want to add javascript
validation... where you should put your abstract base class? You can
only put it on top of all the others (but all other classes in
hierarchy must also be abstract then) or wrap the last extending class
(losing identity). Ok, maybe it isn't a common situation.. anyway with
interface approach, you simple make the last class implements
IClientSideValidator. Do you see any drawback in interfaces?


Cosma


2006/7/12, Cagatay Civici <ca...@gmail.com>:
> Hi,
>
> I'm about to finish my work on the client validation and have faced with a
> design dilemma here.
>
> 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.
>
> As a reminder of the issue;
>
> http://www.irian.at/cagatay-validation-sandbox/home.jsf
>
> Regards,
>
> Cagatay
>

Re: Client Validation Design Discussion

[Matthias Wessendorf <ma...@apache.org>]

> The real question is, should we reimplement all the stuff already
> existing in Trinidad, or should we try hard to make Trinidad work with
> other component libraries too.
> I would like to see the second one instead of reinventing the weel over
> and over again.

see my Renderers email. I'd like to introduce *MyFaces wide* base
renderer structure. Make some of the Trinidad "Faces Major" is also on
my list.

-Matt

Re: Client Validation Design Discussion

[Cagatay Civici <ca...@gmail.com>]

Mario,

Yes, I use addResource for the scriptlet, when I was working on the sandbox.

Since there is not an extended form renderer in tomahawk(for now), I am
using my own custom renderer for testing purposes in my workspace.

I've packed the current "unrefactored" code at my homepage,

www.cagataycivici.com/clientvalidationstuff.rar

Includes all the classes used in the client validation. Simply text
renderers create clientvalidatorcalls by looking at the validators and
queues them in request scope. Then the form renderer renders the script
calls by iterating the queued calls.

Cheers,

Cagatay

On 7/14/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi!
> >
> >     Maybe I can have a look at the ClientConverter stuff?
> >
> >
> > Sure, that would be great Mario.
> Here is a proposal for the client converter stuff.
>
>
> http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/common/converter/
>
>
> Once we approved it, I'll implement it on the tomahawk-sandbox
> convertNumber stuff.
>
> Cagatay, how to you render the client validator scriptlet? Do you use
> addResource? Is there some source code you can point me to?
>
> Ciao,
> Mario
>
>

Re: Client Validation Design Discussion

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
>
>     Maybe I can have a look at the ClientConverter stuff?
>
>
> Sure, that would be great Mario.
Here is a proposal for the client converter stuff.

http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/common/converter/


Once we approved it, I'll implement it on the tomahawk-sandbox
convertNumber stuff.

Cagatay, how to you render the client validator scriptlet? Do you use
addResource? Is there some source code you can point me to?

Ciao,
Mario

Re: Client Validation Design Discussion

[Cagatay Civici <ca...@gmail.com>]

Mario,

Yes, this example explains a alot. Seems I've just needed an example to
figure out the problem :)

Maybe I can have a look at the ClientConverter stuff?


Sure, that would be great Mario.

BTW The extended validators with no conversion requirement is almost
ready:), I'll present another demo next week hopefully.

Cheers,

Cagatay

Re: Client Validation Design Discussion

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
> The user has to
> input a "non valid" value in the context of JS as there is the
> currencySymbol (ok, not very realistic)
Matthias pointed out, that the currencySymbol is used only for output
.... I wonder, but ok, the problem is still the same.

---
Mario

Re: Client Validation Design Discussion

[Mario Ivankovits <ma...@ops.co.at>]

Hi Cagatay!
> A hot discussion we are having here,
Yes, this is great :-)

> I think there is no new API here. Only thing needed is just a single
> interface. As I mentioned before most of the validators do not need
> any conversion before validating the input at all.
This is not necessarily true. Think about the following stuff:
<h:inputText>
    <s:convertNumber
        maxFractionDigits="2"
        minFractionDigits="2"
        currencySymbol="EUR"
        groupingUsed="true"/>
    <f:validateDoubleRange minimum="100" maximum="1000"/>
    <x:mySpecialValidator onlyAllowMultiplesOf="5" />
</h:inputText>

Now lets see about the problems of the convertNumber. The user has to
input a "non valid" value in the context of JS as there is the
currencySymbol (ok, not very realistic) BUT there is also groupingUsed.
The grouping character is locale specific. and There is min/max Fraction
digits which we CAN'T check using the validator only.
On the other hand the validateDoubleRange do not know ANYTHING about how
the user has to enter the value - it will only work on a already
converted number.
The converter has to convert it - locale specific before. And you cant
easily use the locale on the client as the user might have changed the
used locale on the server.
Say you work on an US system but setup your webapp to use the german locale.

This is why the Trinidad guys are right that we have to define a
ClientConverter too.

> btw I'll be glad to receive your help Mario :)
Maybe I can have a look at the ClientConverter stuff?

Ciao,
Mario

Re: Client Validation Design Discussion

[Cagatay Civici <ca...@gmail.com>]

Hi,

A hot discussion we are having here,

I think there is no new API here. Only thing needed is just a single
interface. As I mentioned before most of the validators do not need any
conversion before validating the input at all. We could embed converters
like number and date to the client validation infrastructure since they act
more like a validator at client side and prevent the invalid data to be
posted. They work on java objects at server side, but at client, they could
simply act as a validator.

Let me clarify it, let's say an inputtext has an integeronly converter, the
rendered js function would be something like validateInteger validating
whether the input is an int or not. Date is also the same, validates
according to the pattern. Isn't simple better? just prevent the invalid data
to be posted.

+1 for the validation event like onkeypress, onblur and etc, they are very
useful and very easy to implement by decorating the textrenderer. I've done
it in my current project.

btw I'll be glad to receive your help Mario :)

Cagatay

On 7/13/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi Adam!
>
> Hmmm .... ok, I understand the "chained validator" thing.
>
> So, even if we go the client side converter way, I would like to have a
> way to define the "allowed characters" for the input field.
>
> Maybe by adding a method like
> InputMask getInputMask()
> to the ClientConverter interface. This return a regexp which we can use
> to check onkeypress et al if the input is syntactically correct.
>
> We can have this on the ClientValidator too (for validateEMail,
> validateISBN etc) and always check all masks associated to the field.
>
> A number converter will return "[0-9]*" as mask, but the ClientValidator
> might be smart enough (say a range validator 100-1000) to create a
> regexp like "^[0-9]{0,4}$"
>
> The InputMask might be a structure which returns not only the regexp,
> but also a human readable form of it.
>
> So the converter will return "Numerical Input" and the validator
> something like "In the range from 100 to 1000". We can put this in the
> status line of the browser then to assist the user even more.
>
>
> Yes, you are right that it is better to have the ClientConverter and
> pass this value to the ClientValidator.
> Thanks Adam for the lesson - this is why I like open-source, you will be
> teached for free ;-)
>
> Ciao,
> Mario
>
>

Re: Client Validation Design Discussion

[Mario Ivankovits <ma...@ops.co.at>]

Hi Adam!

Hmmm .... ok, I understand the "chained validator" thing.

So, even if we go the client side converter way, I would like to have a
way to define the "allowed characters" for the input field.

Maybe by adding a method like
InputMask getInputMask()
to the ClientConverter interface. This return a regexp which we can use
to check onkeypress et al if the input is syntactically correct.

We can have this on the ClientValidator too (for validateEMail,
validateISBN etc) and always check all masks associated to the field.

A number converter will return "[0-9]*" as mask, but the ClientValidator
might be smart enough (say a range validator 100-1000) to create a
regexp like "^[0-9]{0,4}$"

The InputMask might be a structure which returns not only the regexp,
but also a human readable form of it.

So the converter will return "Numerical Input" and the validator
something like "In the range from 100 to 1000". We can put this in the
status line of the browser then to assist the user even more.


Yes, you are right that it is better to have the ClientConverter and
pass this value to the ClientValidator.
Thanks Adam for the lesson - this is why I like open-source, you will be
teached for free ;-)

Ciao,
Mario

Re: Client Validation Design Discussion

[Adam Winer <aw...@gmail.com>]

On 7/12/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi Martin!
> > Well, the thing is that a merge is way off on the timeline.
> > And Cagatay has something right now, why not take it in?
> No, I didnt meant to NOT take Cagatys work now. In fact I'd love to see
> it imported soon. Its just the converter stuff I was thinking about.
>
> But now I also think we should put our hands on the converter stuff,
> just, as far as I can see, in Trinidad they implemented a real client
> validator with getAsObject and getAsString - to say the truth, I dont
> like this.
> If we say a converter has also a role as validator (I dont like this
> idea too, but its by their nature that they do validation) I would love
> to see them simply use the same ClientValidator interface than the
> normal validator - On client side we just would like to validate and NOT
> to convert in first place.


Mario,

Two reasons why you really want both methods.

(1) Validators should operate on typesafe objects in JS,
just as they do in Java.  Otherwise, how could you ever
write a client validator for DateRangeValidator without
duplicating the formatting knowledge of the converter?
Therefore, Converters and Validators *aren't* just the same
thing in JS.  You need to first call the Converter (if present),
then call all the Validators with the converted value.

(2) It is very useful to support getAsString() on
Converters in JS, because you can write a Converter that
supports multiple input formats, but canonicalizes to
the preferred format automatically.

(Public APIs in Trinidad generally received quite a lot of team
design effort, so it's usually the case that we *did* have
a reason for designing things the way we did.)

-- Adam






Later, when we see that we really need a client side converter we can
> implement this stuff too, we dont need it for date and number converter,
> the possibility to check onkeypress is much more important.
> I think the client side converter approach isnt really that usable - how
> do you convert a complex (maybe serialized) java object?
>
> So +1 for allowing the ClientValidator interface on the converter too.
>
>
> Ciao,
> Mario
>
>

Re: Client Validation Design Discussion

[Mario Ivankovits <ma...@ops.co.at>]

> But now I also think we should put our hands on the converter stuff,
> just, as far as I can see, in Trinidad they implemented a real client
> validator with getAsObject and getAsString - to say the truth, I dont
>   
sorry, I meant "a real client converter"

Re: Client Validation Design Discussion

[Mario Ivankovits <ma...@ops.co.at>]

Hi Martin!
> Well, the thing is that a merge is way off on the timeline.
> And Cagatay has something right now, why not take it in?
No, I didnt meant to NOT take Cagatys work now. In fact I'd love to see
it imported soon. Its just the converter stuff I was thinking about.

But now I also think we should put our hands on the converter stuff,
just, as far as I can see, in Trinidad they implemented a real client
validator with getAsObject and getAsString - to say the truth, I dont
like this.
If we say a converter has also a role as validator (I dont like this
idea too, but its by their nature that they do validation) I would love
to see them simply use the same ClientValidator interface than the
normal validator - On client side we just would like to validate and NOT
to convert in first place.

Later, when we see that we really need a client side converter we can
implement this stuff too, we dont need it for date and number converter,
the possibility to check onkeypress is much more important.
I think the client side converter approach isnt really that usable - how
do you convert a complex (maybe serialized) java object?

So +1 for allowing the ClientValidator interface on the converter too.


Ciao,
Mario

Re: Client Validation Design Discussion

[Adam Winer <aw...@gmail.com>]

On 7/12/06, Martin Marinschek <ma...@gmail.com> wrote:
>
> Well, the thing is that a merge is way off on the timeline.


True, but OTOH, there's nothing stopping you from grabbing
APIs and code piecemeal from Trinidad today.  That doesn't
need to wait for the grand merge.  And creating new APIs
that are different will just make the merge that much harder
(and push it off even further).  Plus, there is quite an advantage
to taking a codebase that has already been debugged and shipped.

-- Adam


And Cagatay has something right now, why not take it in?




regards,
>
> Martin
>
> On 7/13/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi!
> > >
> > >     > 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.
> > The real question is, should we reimplement all the stuff already
> > existing in Trinidad, or should we try hard to make Trinidad work with
> > other component libraries too.
> > I would like to see the second one instead of reinventing the weel over
> > and over again.
> >
> > Ciao,
> > Mario
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Re: Client Validation Design Discussion

[Martin Marinschek <ma...@gmail.com>]

Well, the thing is that a merge is way off on the timeline.

And Cagatay has something right now, why not take it in?

regards,

Martin

On 7/13/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> >
> >     > 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.
> The real question is, should we reimplement all the stuff already
> existing in Trinidad, or should we try hard to make Trinidad work with
> other component libraries too.
> I would like to see the second one instead of reinventing the weel over
> and over again.
>
> Ciao,
> Mario
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Client Validation Design Discussion

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
>
>     > 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.
The real question is, should we reimplement all the stuff already
existing in Trinidad, or should we try hard to make Trinidad work with
other component libraries too.
I would like to see the second one instead of reinventing the weel over
and over again.

Ciao,
Mario

Re: Client Validation Design Discussion

[Adam Winer <aw...@gmail.com>]

On 7/12/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> 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

Re: Client Validation Design Discussion

[Adam Winer <aw...@gmail.com>]

On 7/12/06, Cagatay Civici <ca...@gmail.com> wrote:
>
> Hi,
>
> Although I fancy the interface design first because of the flexibility,
> since enabling all of the myfaces extended validators to do validation at
> client is necessary, validatorbase still seems the better way. Validatorbase
> is also a nice place for the common client attribute. Anyway maybe a vote is
> needed for the design choice?
>


It's not either one or the other.  We can do both.  Create a validator
interface, *and* make ValidatorBase implement it.  What's the downside?

About the "I" prefix, yes let's forget about it.
>
> Also the client side converters issue, I believe client validation is more
> than the half of the picture because most of the client validators do not
> need any conversion on the input. Some examples are; required attribute,
> length, email, url, equality, regular expression, credit card, isbn. The
> ones that need conversion at client side might be range and compare.
>

But that overlooks all the "validation" done by converters - number
formatting and date formatting in particular.

-- Adam


By the way, these validators run only at onsubmit event of the form. I've
> also implemented simple "onkeypress validation" that allows only integers to
> be entered when there is an integeronly converter by disabling letters, or
> max-min length validation when there is a length validator. I think these
> could be very useful too, what are your thoughts on this? If we all agree,
> I'll include it too.
>
> Cheers
>
> Cagatay,
>
> www.jroller.com/page/cagataycivici
>

Re: Client Validation Design Discussion

[Mario Ivankovits <ma...@ops.co.at>]

>
> TNT would be cooler :)
>
> but Nobago sounds silly :)
*LOL*


---
Mario

Re: Client Validation Design Discussion

[Matthias Wessendorf <ma...@apache.org>]

> Then we should think about porting this to Trinidad as ours is more
> powerful ..... ;-) *just kidding*

mixing best of all worlds is on the list.
On ApacheCon - during some beers (you know ;)) - Bernd and me also
discussed a "common" upload solution for TTT (Tomahawk, Tobago,
Trinidad)

TNT would be cooler :)

but Nobago sounds silly :)

> Cagatay, if there is something I can do to help you out here, just drop
> me a note, I have not that much spare time, but I really would like to
> have this again.
>
> Ciao,
> Mario
>
>


-- 
Matthias Wessendorf

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Client Validation Design Discussion

[Mario Ivankovits <ma...@ops.co.at>]

Hi Cagatay!
> By the way, these validators run only at onsubmit event of the form.
> I've also implemented simple "onkeypress validation" that allows only
> integers to be entered when there is an integeronly converter by
> disabling letters, or max-min length validation when there is a length
> validator. I think these could be very useful too, what are your
> thoughts on this? If we all agree, I'll include it too.

Yes, please. We had such a think in our web-app before and I would love
to see it again. Its very useful for the user.
And, maybe you can make a onchange validator too - the same as onsubmit,
but for this single field only.

So, we end up in:
*) onkeypress check which avoids to enter invalid chars
*) onchange check to show an error as soon as the user leaves the field
*) onsubmit check for a last overall check (maybe with stuff like
from/to checks, I know, not yet)

Then we should think about porting this to Trinidad as ours is more
powerful ..... ;-) *just kidding*

Cagatay, if there is something I can do to help you out here, just drop
me a note, I have not that much spare time, but I really would like to
have this again.

Ciao,
Mario

Re: Client Validation Design Discussion

[Cagatay Civici <ca...@gmail.com>]

Hi,

Although I fancy the interface design first because of the flexibility,
since enabling all of the myfaces extended validators to do validation at
client is necessary, validatorbase still seems the better way. Validatorbase
is also a nice place for the common client attribute. Anyway maybe a vote is
needed for the design choice?

About the "I" prefix, yes let's forget about it.

Also the client side converters issue, I believe client validation is more
than the half of the picture because most of the client validators do not
need any conversion on the input. Some examples are; required attribute,
length, email, url, equality, regular expression, credit card, isbn. The
ones that need conversion at client side might be range and compare.

By the way, these validators run only at onsubmit event of the form. I've
also implemented simple "onkeypress validation" that allows only integers to
be entered when there is an integeronly converter by disabling letters, or
max-min length validation when there is a length validator. I think these
could be very useful too, what are your thoughts on this? If we all agree,
I'll include it too.

Cheers

Cagatay,

www.jroller.com/page/cagataycivici

Re: Client Validation Design Discussion

[Matthias Wessendorf <ma...@apache.org>]

> 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 saw this
http://jcp.org/en/jsr/detail?id=303
during my daily blog reading, yesterday

> > 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?
>
> > 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 :-)

sure! ;)

> Ciao,
> Mario
>
>


-- 
Matthias Wessendorf

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Client Validation Design Discussion

[Mario Ivankovits <ma...@ops.co.at>]

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). 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?

> 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 :-)

Ciao,
Mario

Re: Client Validation Design Discussion

[Adam Winer <aw...@gmail.com>]

I think that having a ValidatorBase is reasonable enough, but that
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 <ma...@ops.co.at> 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
>
>

Re: Client Validation Design Discussion

[Mario Ivankovits <ma...@ops.co.at>]

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

Re: Client Validation Design Discussion

[Cagatay Civici <ca...@gmail.com>]

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 <ma...@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
>
>

Re: Client Validation Design Discussion

[Mario Ivankovits <ma...@ops.co.at>]

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