You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Manuel Corrales <ma...@gmail.com> on 2008/06/24 22:17:08 UTC
Client side validation
Hi, i dont want to be flamed by this post, i have read on some places some
not very polite things about wicket vs taperstry. I think that all
frameworks have pro and cons. Here is the thing, i was using Tapestry 5 for
a while, and now i am developing with wicket. One thing i liked about T5 was
the "magic" on the client side validation without the need to write
javascript, and it worked pretty good. I really do not have the time now,
but it would be great to accomplish something like this:
RequiredTextField tf = new....
tf.enableClientSideValidation();
my approach would be to borrow the T5 code to generate the required
javascript.
Is this idea worth the time?
Best regards.
Manuel.
Re: Client side validation
Posted by Matthijs Wensveen <m....@func.nl>.
Yes, of course. But the form is not posted when the client side does not
validate. Of course the posted form is validated on the server too.
Anyway, the nice thing is that you only have to say something like
setClientSideValidation(true) and it just works. It's all very
transparent, which is cool. I'm not a M$ fanboy or anything (if I was, I
wouldn't even be typing this), but I did like that particular feature.
Johan Compagner wrote:
> Fallback? That should always be done fallback or not, clientside is
> jus a quicker feedback to the user, the real validation should always
> be done after that on the serverside
>
> On 6/26/08, Matthijs Wensveen <m....@func.nl> wrote:
>
>> I know ASP.Net has this too, and falls back to the server when client
>> side validation is not possible (or is hacked by a smarter than average
>> user). Something could be done. I think would be worth the time when you
>> have it (time, that is). I'd start with a separate project, so that
>> people can try it out.
>>
>> Matthijs
>>
>> Manuel Corrales wrote:
>>
>>> Hi, i dont want to be flamed by this post, i have read on some places some
>>> not very polite things about wicket vs taperstry. I think that all
>>> frameworks have pro and cons. Here is the thing, i was using Tapestry 5
>>> for
>>> a while, and now i am developing with wicket. One thing i liked about T5
>>> was
>>> the "magic" on the client side validation without the need to write
>>> javascript, and it worked pretty good. I really do not have the time now,
>>> but it would be great to accomplish something like this:
>>>
>>> RequiredTextField tf = new....
>>> tf.enableClientSideValidation();
>>>
>>> my approach would be to borrow the T5 code to generate the required
>>> javascript.
>>>
>>> Is this idea worth the time?
>>>
>>> Best regards.
>>>
>>> Manuel.
>>>
>>>
>>>
>> --
>> Matthijs Wensveen
>> Func. Internet Integration
>> W http://www.func.nl
>> T +31 20 4230000
>> F +31 20 4223500
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Client side validation
Posted by Johan Compagner <jc...@gmail.com>.
Fallback? That should always be done fallback or not, clientside is
jus a quicker feedback to the user, the real validation should always
be done after that on the serverside
On 6/26/08, Matthijs Wensveen <m....@func.nl> wrote:
> I know ASP.Net has this too, and falls back to the server when client
> side validation is not possible (or is hacked by a smarter than average
> user). Something could be done. I think would be worth the time when you
> have it (time, that is). I'd start with a separate project, so that
> people can try it out.
>
> Matthijs
>
> Manuel Corrales wrote:
>> Hi, i dont want to be flamed by this post, i have read on some places some
>> not very polite things about wicket vs taperstry. I think that all
>> frameworks have pro and cons. Here is the thing, i was using Tapestry 5
>> for
>> a while, and now i am developing with wicket. One thing i liked about T5
>> was
>> the "magic" on the client side validation without the need to write
>> javascript, and it worked pretty good. I really do not have the time now,
>> but it would be great to accomplish something like this:
>>
>> RequiredTextField tf = new....
>> tf.enableClientSideValidation();
>>
>> my approach would be to borrow the T5 code to generate the required
>> javascript.
>>
>> Is this idea worth the time?
>>
>> Best regards.
>>
>> Manuel.
>>
>>
>
>
> --
> Matthijs Wensveen
> Func. Internet Integration
> W http://www.func.nl
> T +31 20 4230000
> F +31 20 4223500
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Sent from Gmail for mobile | mobile.google.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Client side validation
Posted by Matthijs Wensveen <m....@func.nl>.
I know ASP.Net has this too, and falls back to the server when client
side validation is not possible (or is hacked by a smarter than average
user). Something could be done. I think would be worth the time when you
have it (time, that is). I'd start with a separate project, so that
people can try it out.
Matthijs
Manuel Corrales wrote:
> Hi, i dont want to be flamed by this post, i have read on some places some
> not very polite things about wicket vs taperstry. I think that all
> frameworks have pro and cons. Here is the thing, i was using Tapestry 5 for
> a while, and now i am developing with wicket. One thing i liked about T5 was
> the "magic" on the client side validation without the need to write
> javascript, and it worked pretty good. I really do not have the time now,
> but it would be great to accomplish something like this:
>
> RequiredTextField tf = new....
> tf.enableClientSideValidation();
>
> my approach would be to borrow the T5 code to generate the required
> javascript.
>
> Is this idea worth the time?
>
> Best regards.
>
> Manuel.
>
>
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Client side validation
Posted by Ryan Sonnek <ry...@gmail.com>.
Okay, I've attached a patch that adds the maxlength html attribute.
On Tue, Jul 1, 2008 at 11:24 AM, Eelco Hillenius <ee...@gmail.com>
wrote:
> On Tue, Jul 1, 2008 at 7:11 AM, Ryan Sonnek <ry...@gmail.com> wrote:
> > Do any of the core validators actually implement this interface?
>
> Not yet I think, but it's never to late :-)
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Client side validation
Posted by Eelco Hillenius <ee...@gmail.com>.
On Tue, Jul 1, 2008 at 7:11 AM, Ryan Sonnek <ry...@gmail.com> wrote:
> Do any of the core validators actually implement this interface?
Not yet I think, but it's never to late :-)
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Client side validation
Posted by Ryan Sonnek <ry...@gmail.com>.
Do any of the core validators actually implement this interface?
I have an issue filed in JIRA for the StringValidator.maximumLength()
validator to append the maxlength HTML attribute to form components.
https://issues.apache.org/jira/browse/WICKET-1310
This seems like a perfect place to implement this feature.
On Mon, Jun 30, 2008 at 12:53 PM, Eelco Hillenius <ee...@gmail.com>
wrote:
> > That's why we introduced IValidatorAddListener in the past if I
> > remember correctly. I validator that implements IValidatorAddListener
> > can add behaviors in the onAdded method, so it is already possible to
> > design validators that take care of both server- and client side
> > validation.
>
> Javadocs from that class:
>
> public interface IValidatorAddListener extends IClusterable
> {
> /**
> * Called right after a validator is added to a {@link Form} or
> {@link FormComponent}. A common
> * use case for implementing this interface is for validators to add
> behaviors to implement
> * client-side validation capabilities, e.g. through JavaScript,
> Ajax
> or just by adding a simple
> * attribute modifier that sets a "maxlength" attribute.
> *
> * @param component
> * a <code>Component</code> to which the validator was
> just added
> */
> void onAdded(Component component);
> }
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Client side validation
Posted by Eelco Hillenius <ee...@gmail.com>.
> That's why we introduced IValidatorAddListener in the past if I
> remember correctly. I validator that implements IValidatorAddListener
> can add behaviors in the onAdded method, so it is already possible to
> design validators that take care of both server- and client side
> validation.
Javadocs from that class:
public interface IValidatorAddListener extends IClusterable
{
/**
* Called right after a validator is added to a {@link Form} or
{@link FormComponent}. A common
* use case for implementing this interface is for validators to add
behaviors to implement
* client-side validation capabilities, e.g. through JavaScript, Ajax
or just by adding a simple
* attribute modifier that sets a "maxlength" attribute.
*
* @param component
* a <code>Component</code> to which the validator was just added
*/
void onAdded(Component component);
}
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Client side validation
Posted by Eelco Hillenius <ee...@gmail.com>.
On Tue, Jun 24, 2008 at 2:07 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> the reason we have not done this is that client side validation is
> limited. also a lot of applications want a consistent look and feel
> for javascript validation, which is not possible via a framework. what
> we are going to do in 1.5 is allow ivalidator to also implement
> ibehavior, this will allow a clean way of spitting out the javascript
> from a validator, which is where it belongs.
That's why we introduced IValidatorAddListener in the past if I
remember correctly. I validator that implements IValidatorAddListener
can add behaviors in the onAdded method, so it is already possible to
design validators that take care of both server- and client side
validation.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Client side validation
Posted by Igor Vaynberg <ig...@gmail.com>.
yes
-igor
On Tue, Jun 24, 2008 at 2:38 PM, Manuel Corrales
<ma...@gmail.com> wrote:
> Ok, great. I dont fully get what is the issue with the look and feel? Do you
> mean the way that errors are displayed? (popups, colored inputs, lists)
>
> Manuel.
>
> On Tue, Jun 24, 2008 at 6:07 PM, Igor Vaynberg <ig...@gmail.com>
> wrote:
>
>> the reason we have not done this is that client side validation is
>> limited. also a lot of applications want a consistent look and feel
>> for javascript validation, which is not possible via a framework. what
>> we are going to do in 1.5 is allow ivalidator to also implement
>> ibehavior, this will allow a clean way of spitting out the javascript
>> from a validator, which is where it belongs.
>>
>> for now we have a half-way solution which uses ajax and has the
>> advantages of having the same look and feel and being able to validate
>> server-side validation rules that cannot be validated on client alone.
>>
>> -igor
>>
>> On Tue, Jun 24, 2008 at 1:17 PM, Manuel Corrales
>> <ma...@gmail.com> wrote:
>> > Hi, i dont want to be flamed by this post, i have read on some places
>> some
>> > not very polite things about wicket vs taperstry. I think that all
>> > frameworks have pro and cons. Here is the thing, i was using Tapestry 5
>> for
>> > a while, and now i am developing with wicket. One thing i liked about T5
>> was
>> > the "magic" on the client side validation without the need to write
>> > javascript, and it worked pretty good. I really do not have the time now,
>> > but it would be great to accomplish something like this:
>> >
>> > RequiredTextField tf = new....
>> > tf.enableClientSideValidation();
>> >
>> > my approach would be to borrow the T5 code to generate the required
>> > javascript.
>> >
>> > Is this idea worth the time?
>> >
>> > Best regards.
>> >
>> > Manuel.
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Client side validation
Posted by Manuel Corrales <ma...@gmail.com>.
Ok, great. I dont fully get what is the issue with the look and feel? Do you
mean the way that errors are displayed? (popups, colored inputs, lists)
Manuel.
On Tue, Jun 24, 2008 at 6:07 PM, Igor Vaynberg <ig...@gmail.com>
wrote:
> the reason we have not done this is that client side validation is
> limited. also a lot of applications want a consistent look and feel
> for javascript validation, which is not possible via a framework. what
> we are going to do in 1.5 is allow ivalidator to also implement
> ibehavior, this will allow a clean way of spitting out the javascript
> from a validator, which is where it belongs.
>
> for now we have a half-way solution which uses ajax and has the
> advantages of having the same look and feel and being able to validate
> server-side validation rules that cannot be validated on client alone.
>
> -igor
>
> On Tue, Jun 24, 2008 at 1:17 PM, Manuel Corrales
> <ma...@gmail.com> wrote:
> > Hi, i dont want to be flamed by this post, i have read on some places
> some
> > not very polite things about wicket vs taperstry. I think that all
> > frameworks have pro and cons. Here is the thing, i was using Tapestry 5
> for
> > a while, and now i am developing with wicket. One thing i liked about T5
> was
> > the "magic" on the client side validation without the need to write
> > javascript, and it worked pretty good. I really do not have the time now,
> > but it would be great to accomplish something like this:
> >
> > RequiredTextField tf = new....
> > tf.enableClientSideValidation();
> >
> > my approach would be to borrow the T5 code to generate the required
> > javascript.
> >
> > Is this idea worth the time?
> >
> > Best regards.
> >
> > Manuel.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Client side validation
Posted by Igor Vaynberg <ig...@gmail.com>.
the reason we have not done this is that client side validation is
limited. also a lot of applications want a consistent look and feel
for javascript validation, which is not possible via a framework. what
we are going to do in 1.5 is allow ivalidator to also implement
ibehavior, this will allow a clean way of spitting out the javascript
from a validator, which is where it belongs.
for now we have a half-way solution which uses ajax and has the
advantages of having the same look and feel and being able to validate
server-side validation rules that cannot be validated on client alone.
-igor
On Tue, Jun 24, 2008 at 1:17 PM, Manuel Corrales
<ma...@gmail.com> wrote:
> Hi, i dont want to be flamed by this post, i have read on some places some
> not very polite things about wicket vs taperstry. I think that all
> frameworks have pro and cons. Here is the thing, i was using Tapestry 5 for
> a while, and now i am developing with wicket. One thing i liked about T5 was
> the "magic" on the client side validation without the need to write
> javascript, and it worked pretty good. I really do not have the time now,
> but it would be great to accomplish something like this:
>
> RequiredTextField tf = new....
> tf.enableClientSideValidation();
>
> my approach would be to borrow the T5 code to generate the required
> javascript.
>
> Is this idea worth the time?
>
> Best regards.
>
> Manuel.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org