Enabling Client Side Validation

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

Hi,

I want to introduce the idea that I've come up with when I was working on
the integration of the client side validation support for myFaces. Martin
and I agreed this is the optimal solution for the problem for now.

The aim is to minimize the effort of the myfaces user and do not break
anything in the jsf pages already created. In order to do this,I've added a
few lines of code to the inputtextrenderer and extended the form renderer.

Each inputtextrenderer checks for the validators like required attribute and
queues a ClientValidatorCall object for each of them. This
ClientValidatorCall object consists of the js function name, and parameters.
The queue is hold using a request scope ClientValidatosCalls bean. This bean
has a set of ClientValidatorCall objects.

After the form renderer does it's job, it accessed the ClientValidatorCalls
bean and encodes the js function calls by iterating the queue.

Main advantages are the following;
"* Users do not need to change anything in their pages."
* A context param called ENABLE_CLIENT_VALIDATION acts a switch to turn
on/off the client validation.
* By default validation messages are displayed using the t:message and
t:messages components.
* If desired popups can also be used to display the error messages.
* Validation can run onsubmit, onblur, onkeypress and etc. All depends on
the user's wish.

I've implemented this idea, to make the required attribute's validation on
client. It worked like a charm, and the best thing is I've not changed
anything on the page.

To clarify the idea, I could say it looks like the relationship between
facesmessages and h:messages component. As you know h:messages accesses the
facesmessages added and renders them. Similiar to formrenderer and
validationcalls.

I'd be glad to hear your thoughts on this, If it is all agreed, I'll start
providing the patches.

Regards,

Cagatay Civici
www.jroller.com/page/cagataycivici

Re: Enabling Client Side Validation

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

Hi Adam!
> First, using one Validator class and one JSP tag for all
> of the different types is painful for users and tools support.
Yes.

> client-side validation should always  be *in addition* to server-side
> validation.
Which should be the default for sure, I dont think that it soo bad if
the user has additional decisions.

> Third, you should not have
> to attach a validator tag to get "required" client-side validation
> working;
As JSF currently is, it is the easiest way to handle this that way,
else, you have to install a custom renderer - you know about the
downsides of it.
But for sure, it would be great to have this comfort.

> Finally, using a date "validator" for verifying formats of dates is
> wrong;  format masks should get checked by Converters, not Validators.
Its by the nature of a converter to fail if the mask didnt match,
though, its arguable to say the validator will check the input at first, no?
A converter can be much more complicated so that you cant easily check
this by a client side validator, but describing only the syntax should
be easy. The validator checks the syntax and the converter converts the
value to an object, no?

Notice, I was just an idea. Cagaty is nearly finished with his work, so
including shale-validator is no longer in discussion. So lets see if his
work fits our needs.

Ciao,
Mario

Re: Enabling Client Side Validation

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

On 6/6/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Matthias!
> > You mean client/server attribute?
> > this is a no-no (search the mail archive)
> I know about the limitations of its current approach, but I meant to
> extend this library to honor a global flag too.
> I remember Craig isnt against such a flag - I think its just a matter of
> no time.
>
> > To me Cagatay's solution is better.
> So extend Craigs validation solution with such an global configuration
> flag and you are done.

Not Craig's, IIRC;  I thought David Geary did at least the initial work.

Frankly, I find the Shale Validator code rather poor from a variety
of angles.  First, using one Validator class and one JSP tag for all
of the different types is painful for users and tools support.  Second,
supporting "client-only" validation (client=true, server=false) is a bad
idea that should not be copied;  client-side validation should always
be *in addition* to server-side validation.  Third, you should not have
to attach a validator tag to get "required" client-side validation
working;  that should only require setting required="true" on the
component (and setting the global flag to activate client-side validation).
Finally, using a date "validator" for verifying formats of dates is
wrong;  format masks should get checked by Converters, not Validators.

So, I'm -1 for extending any of that codebase.  MyFaces can do much
better.

-- Adam

Re: Enabling Client Side Validation

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

Hi Matthias!
> You mean client/server attribute?
> this is a no-no (search the mail archive)
I know about the limitations of its current approach, but I meant to
extend this library to honor a global flag too.
I remember Craig isnt against such a flag - I think its just a matter of
no time.

> To me Cagatay's solution is better.
So extend Craigs validation solution with such an global configuration
flag and you are done.

Ciao,
Mario

Re: Enabling Client Side Validation

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

You mean client/server attribute?

this is a no-no (search the mail archive)

It shouldn't be up to the page admin to change lots of validator tags
just in case of
client side instead of server side is desired. or vice versa.

To me Cagatay's solution is better.

-Matthias

On 6/6/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > Please use some "org.apache.myfaces..." namespace in front of
> > ENABLE_CLIENT_SIDE_VALIDATION
> What about integrate
> http://struts.apache.org/struts-shale/features-commons-validator.html
> into tomahawk?
> Then a simple global configuration parameter is missing, no?
>
> Ciao,
> Mario
>
>


-- 
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Enabling Client Side Validation

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

Hi!
> Please use some "org.apache.myfaces..." namespace in front of
> ENABLE_CLIENT_SIDE_VALIDATION
What about integrate
http://struts.apache.org/struts-shale/features-commons-validator.html
into tomahawk?
Then a simple global configuration parameter is missing, no?

Ciao,
Mario

Re: Enabling Client Side Validation

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

Cagatay,

sounds very cool!

Please use some "org.apache.myfaces..." namespace in front of
ENABLE_CLIENT_SIDE_VALIDATION

-Matthias

On 6/5/06, Grant Smith <wo...@gmail.com> wrote:
> Seems like a good, clean approach. I say go ahead, as it will not break
> anything as the user has to specify the ENABLE_CLIENT_VALIDATION parameter.
> Good innovation !
>
>
> On 6/5/06, Cagatay Civici <ca...@gmail.com> wrote:
> >
> > Hi,
> >
> > I want to introduce the idea that I've come up with when I was working on
> the integration of the client side validation support for myFaces. Martin
> and I agreed this is the optimal solution for the problem for now.
> >
> > The aim is to minimize the effort of the myfaces user and do not break
> anything in the jsf pages already created. In order to do this,I've added a
> few lines of code to the inputtextrenderer and extended the form renderer.
> >
> > Each inputtextrenderer checks for the validators like required attribute
> and queues a ClientValidatorCall object for each of them. This
> ClientValidatorCall object consists of the js function name, and parameters.
> The queue is hold using a request scope ClientValidatosCalls bean. This bean
> has a set of ClientValidatorCall objects.
> >
> > After the form renderer does it's job, it accessed the
> ClientValidatorCalls bean and encodes the js function calls by iterating the
> queue.
> >
> > Main advantages are the following;
> > "* Users do not need to change anything in their pages."
> > * A context param called ENABLE_CLIENT_VALIDATION acts a switch to turn
> on/off the client validation.
> > * By default validation messages are displayed using the t:message and
> t:messages components.
> > * If desired popups can also be used to display the error messages.
> > * Validation can run onsubmit, onblur, onkeypress and etc. All depends on
> the user's wish.
> >
> > I've implemented this idea, to make the required attribute's validation on
> client. It worked like a charm, and the best thing is I've not changed
> anything on the page.
> >
> > To clarify the idea, I could say it looks like the relationship between
> facesmessages and h:messages component. As you know h:messages accesses the
> facesmessages added and renders them. Similiar to formrenderer and
> validationcalls.
> >
> > I'd be glad to hear your thoughts on this, If it is all agreed, I'll start
> providing the patches.
> >
> > Regards,
> >
> >
> > Cagatay Civici
> > www.jroller.com/page/cagataycivici
>
>
>
> --
> Grant Smith
>


-- 
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Enabling Client Side Validation

[Grant Smith <wo...@gmail.com>]

Seems like a good, clean approach. I say go ahead, as it will not break
anything as the user has to specify the ENABLE_CLIENT_VALIDATION parameter.
Good innovation !

On 6/5/06, Cagatay Civici <ca...@gmail.com> wrote:
>
> Hi,
>
> I want to introduce the idea that I've come up with when I was working on
> the integration of the client side validation support for myFaces. Martin
> and I agreed this is the optimal solution for the problem for now.
>
> The aim is to minimize the effort of the myfaces user and do not break
> anything in the jsf pages already created. In order to do this,I've added a
> few lines of code to the inputtextrenderer and extended the form renderer.
>
> Each inputtextrenderer checks for the validators like required attribute
> and queues a ClientValidatorCall object for each of them. This
> ClientValidatorCall object consists of the js function name, and parameters.
> The queue is hold using a request scope ClientValidatosCalls bean. This bean
> has a set of ClientValidatorCall objects.
>
> After the form renderer does it's job, it accessed the
> ClientValidatorCalls bean and encodes the js function calls by iterating the
> queue.
>
> Main advantages are the following;
> "* Users do not need to change anything in their pages."
> * A context param called ENABLE_CLIENT_VALIDATION acts a switch to turn
> on/off the client validation.
> * By default validation messages are displayed using the t:message and
> t:messages components.
> * If desired popups can also be used to display the error messages.
> * Validation can run onsubmit, onblur, onkeypress and etc. All depends on
> the user's wish.
>
> I've implemented this idea, to make the required attribute's validation on
> client. It worked like a charm, and the best thing is I've not changed
> anything on the page.
>
> To clarify the idea, I could say it looks like the relationship between
> facesmessages and h:messages component. As you know h:messages accesses the
> facesmessages added and renders them. Similiar to formrenderer and
> validationcalls.
>
> I'd be glad to hear your thoughts on this, If it is all agreed, I'll start
> providing the patches.
>
> Regards,
>
> Cagatay Civici
> www.jroller.com/page/cagataycivici
>



-- 
Grant Smith