Re: Server and client side validation
Hi Gabriel,
On Tue, May 14, 2013 at 12:43 AM, Gabriel Landon glan...@piti.pf wrote:
Hi Martin,
It does work with the following code:
/return $('#%s').closest('form').parsley( 'validate' );/
Thank you very much.
To find out whether the form is in a ModalWindow or not, I've used the
following code:
/@Override
public void renderHead(final IHeaderResponse varResponse) {
super.renderHead(varResponse);
// starts parsley for this form
if (this.findParent(ModalWindow.class) == null) {
I think you should look for the root form instead of a ModalWindow.
You can have nested forms in your app without ModalWindow around.
See org.apache.wicket.markup.html.form.Form#findForm
and org.apache.wicket.markup.html.form.Form#getRootForm
varResponse
.render(OnDomReadyHeaderItem.forScript(String.format($('#%s').parsley();,
this.getMarkupId(;
} else {
varResponse.render(OnDomReadyHeaderItem.forScript(String.format($('#%s').closest('form').parsley();,
this.getMarkupId(;
}
}/
Is there a better way to do that, or is it OK?
Regards,
Gabriel.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Server-and-client-side-validation-tp4658242p4658773.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
Wicket Training Consulting
http://jWeekend.com http://jweekend.com/
Re: Server and client side validation
Martin,
Thank you it was even easier than I though.
/// starts parsley for this form (or the root form)
final Form? form = (Form?) component;
varResponse.render(OnDomReadyHeaderItem.forScript(String.format($('#%s').parsley();,
form.getRootForm()
.getMarkupId(;/
Regards,
Gabriel
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Server-and-client-side-validation-tp4658242p4658795.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Server and client side validation
Hi Martin,
It does work with the following code:
/return $('#%s').closest('form').parsley( 'validate' );/
Thank you very much.
To find out whether the form is in a ModalWindow or not, I've used the
following code:
/@Override
public void renderHead(final IHeaderResponse varResponse) {
super.renderHead(varResponse);
// starts parsley for this form
if (this.findParent(ModalWindow.class) == null) {
varResponse
.render(OnDomReadyHeaderItem.forScript(String.format($('#%s').parsley();,
this.getMarkupId(;
} else {
varResponse.render(OnDomReadyHeaderItem.forScript(String.format($('#%s').closest('form').parsley();,
this.getMarkupId(;
}
}/
Is there a better way to do that, or is it OK?
Regards,
Gabriel.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Server-and-client-side-validation-tp4658242p4658773.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Server and client side validation
Hi, I've not yet tried to plug it inside a modal window. But I see no reason for it to fail. Le 7 mai 2013 20:15, Gabriel Landon glan...@piti.pf a écrit : Hi Cedric, Yes I've seen what you have done. Did you manage to make it works with forms in ModalWindow? Regards, Gabriel. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Server-and-client-side-validation-tp4658242p4658631.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Server and client side validation
Hi Gabriel,
I guess ParsleyJS checks that the parameter for #validate() is a 'form'
element.
Since this is a nested form Wicket transforms it to a DIV, because
otherwise the HTML will not be valid.
Wicket knows how to deal with submitting nested forms but you have to do
some manual work for Parsley -
Parsley.validate($('#nestedFormId').closest('form')[0]), or something like
this.
On Wed, May 8, 2013 at 8:02 AM, Cedric Gatay gata...@gmail.com wrote:
Hi,
I've not yet tried to plug it inside a modal window. But I see no reason
for it to fail.
Le 7 mai 2013 20:15, Gabriel Landon glan...@piti.pf a écrit :
Hi Cedric,
Yes I've seen what you have done.
Did you manage to make it works with forms in ModalWindow?
Regards,
Gabriel.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Server-and-client-side-validation-tp4658242p4658631.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
Wicket Training Consulting
http://jWeekend.com http://jweekend.com/
Re: Server and client side validation
Hi Gabriel, the spin-off from Martin's blog post is available on Maven Central (via Sonatype OSS services). It depends on JSR303 though. Regards, __ Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_Gatay) http://code-troopers.com | http://www.bloggure.info | http://cedric.gatay.fr On Tue, May 7, 2013 at 2:37 AM, Gabriel Landon glan...@piti.pf wrote: Martin, I've create a ParsleyRangeValidator and a ParsleyLengthValidator very easily thanks to your code. I've also create ParsleyForm that initializes Parsley in the RenderHead and a ParsleyAjaxButton that validates Parsley on submit. I only have one problem with forms in a ModalWindow. As the form tag is replace with a div tag, Parsley doesn't seems to work in this case. Do you have an idea on how to fix that? Regards, Gabriel. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Server-and-client-side-validation-tp4658242p4658602.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Server and client side validation
Hi Cedric, Yes I've seen what you have done. Did you manage to make it works with forms in ModalWindow? Regards, Gabriel. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Server-and-client-side-validation-tp4658242p4658631.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Server and client side validation
Martin, That's a great project! That's exactly what I've been waiting for! It would be very nice to have it in wicketstuff so we could upload it with maven and maybe extend it. Regards, Gabriel. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Server-and-client-side-validation-tp4658242p4658601.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Server and client side validation
Martin, I've create a ParsleyRangeValidator and a ParsleyLengthValidator very easily thanks to your code. I've also create ParsleyForm that initializes Parsley in the RenderHead and a ParsleyAjaxButton that validates Parsley on submit. I only have one problem with forms in a ModalWindow. As the form tag is replace with a div tag, Parsley doesn't seems to work in this case. Do you have an idea on how to fix that? Regards, Gabriel. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Server-and-client-side-validation-tp4658242p4658602.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Server and client side validation
Hi, Your blog post helped me write my first version of the integration between JSR303 (bean-validation) and client side validation using parsley.js. You can find the current work on this Github repository: https://github.com/code-troopers/wicket-jsr303-parsley Regards, __ Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_Gatay) http://code-troopers.com | http://www.bloggure.info | http://cedric.gatay.fr On Wed, Apr 24, 2013 at 7:23 PM, Cedric Gatay gata...@gmail.com wrote: Thanks Martin, I was just wondering how I could do that. Nice library and nice integration with Wicket. Regards Le 24 avr. 2013 18:07, Martin Grigorov mgrigo...@apache.org a écrit : Hi, I just posted a new article at http://wicketinaction.com/2013/04/server-and-client-side-validation/about integrating Wicket with client side validation library. Enjoy! -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: Server and client side validation
Thanks for sharing, Cedric! Well done! On Tue, Apr 30, 2013 at 9:19 AM, Cedric Gatay gata...@gmail.com wrote: Hi, Your blog post helped me write my first version of the integration between JSR303 (bean-validation) and client side validation using parsley.js. You can find the current work on this Github repository: https://github.com/code-troopers/wicket-jsr303-parsley Regards, __ Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_Gatay) http://code-troopers.com | http://www.bloggure.info | http://cedric.gatay.fr On Wed, Apr 24, 2013 at 7:23 PM, Cedric Gatay gata...@gmail.com wrote: Thanks Martin, I was just wondering how I could do that. Nice library and nice integration with Wicket. Regards Le 24 avr. 2013 18:07, Martin Grigorov mgrigo...@apache.org a écrit : Hi, I just posted a new article at http://wicketinaction.com/2013/04/server-and-client-side-validation/about integrating Wicket with client side validation library. Enjoy! -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/ -- Martin Grigorov Wicket Training Consulting http://jWeekend.com http://jweekend.com/
Server and client side validation
Hi, I just posted a new article at http://wicketinaction.com/2013/04/server-and-client-side-validation/ about integrating Wicket with client side validation library. Enjoy! -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: Server and client side validation
Thanks Martin, I was just wondering how I could do that. Nice library and nice integration with Wicket. Regards Le 24 avr. 2013 18:07, Martin Grigorov mgrigo...@apache.org a écrit : Hi, I just posted a new article at http://wicketinaction.com/2013/04/server-and-client-side-validation/ about integrating Wicket with client side validation library. Enjoy! -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: Client side validation behaviors - already started?
First thing that I have to notice: ClientAndServerExactLengthValidatingBehavior is an awful class name. LengthValidation would be enough. The other thing: I wouldn't use clientside validation when it validates on submit only. It should validate non-empty fields on blur, and fields already marked as invalid on keyup. Without that there really isn't much of a point in using clientside validation at all. I'll try to look at your actual code, though some examples would help a lot! Jörn On Sun, Oct 5, 2008 at 7:33 AM, Jeremy Thomerson [EMAIL PROTECTED] wrote: Okay, I was able to commit what I had already started on. This is only a few hours work, so it is nowhere near complete. However, I have the basis for the framework, and a replica of all the StringValidator validation done. https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-client-and-server-validation/ Here are the basic features: - By simply replacing formcomponent.add(StringValidator.exactLength(4)) with add(new ClientAndServerExactLengthValidatingBehavior(form, 4)), it will do the client side validation and add the server side IValidator for you. - It is internationalized because it uses all of the same resource keys / messages that the standard Wicket validators use. - It can insert feedback messages onto the page in a feedback panel or other WebMarkupContainer by calling feedbackpanel.add(new ClientAndServerValidatingFeedbackBehavior(form)) - this will make it use the same appearance that the normal feedback panel would generate. I'm sure there is quite a bit of stuff that can be cleaned up, especially in the JS code. For instance, I'm using document.getElementById quite a bit, but I'm not sure if there are some browsers that may not support that. I need to look because I can't remember. Anyway, feedback is welcome! NOTE: I had started it within another project and was testing it there. I have not had time to test it again after I moved it to its own project. Since all I did was move it, add the license info and rename the packages, it should still work, but you know how that goes. -- Jeremy Thomerson http://www.wickettraining.com On Sat, Oct 4, 2008 at 9:39 AM, Jeremy Thomerson [EMAIL PROTECTED]wrote: Basically, where you would normally call: Formcomponent.add(IValidator), You could now add a behavior. In my behavior, on bind I add the server-side equivalent validator. Then in renderHead, I add some onLoad JS that adds the component to a JS array of components to be validated on form submit. Let me get a little more of the basic started, and then I would REALLY welcome the help! Maybe tomorrow night or Monday I can get a wicketstuff project started for it... The help will be great - my JS fu is rusty! Jeremy Thomerson http://www.wickettraining.com -- sent from a wireless device -Original Message- From: Jörn Zaefferer =F6rn_Zaefferer _ [EMAIL PROTECTED] Sent: Saturday, October 04, 2008 5:50 AM To: users@wicket.apache.org Subject: Re: Client side validation behaviors - already started? What approach for client-side validation are you looking for? I may be able to help with that. Jörn On Fri, Oct 3, 2008 at 5:50 AM, Jeremy Thomerson [EMAIL PROTECTED] wrote: I've been thinking of trying to create some behaviors that combine the standard server-side validation with client-side validation. I just wanted to check to see if anyone knew of something like this already started. I don't want to duplicate work already done. Thanks, -- Jeremy Thomerson http://www.wickettraining.com
Re: Client side validation behaviors - already started?
What approach for client-side validation are you looking for? I may be able to help with that. Jörn On Fri, Oct 3, 2008 at 5:50 AM, Jeremy Thomerson [EMAIL PROTECTED] wrote: I've been thinking of trying to create some behaviors that combine the standard server-side validation with client-side validation. I just wanted to check to see if anyone knew of something like this already started. I don't want to duplicate work already done. Thanks, -- Jeremy Thomerson http://www.wickettraining.com
RE: Client side validation behaviors - already started?
Basically, where you would normally call: Formcomponent.add(IValidator), You could now add a behavior. In my behavior, on bind I add the server-side equivalent validator. Then in renderHead, I add some onLoad JS that adds the component to a JS array of components to be validated on form submit. Let me get a little more of the basic started, and then I would REALLY welcome the help! Maybe tomorrow night or Monday I can get a wicketstuff project started for it... The help will be great - my JS fu is rusty! Jeremy Thomerson http://www.wickettraining.com -- sent from a wireless device -Original Message- From: Jörn Zaefferer =F6rn_Zaefferer _ [EMAIL PROTECTED] Sent: Saturday, October 04, 2008 5:50 AM To: users@wicket.apache.org Subject: Re: Client side validation behaviors - already started? What approach for client-side validation are you looking for? I may be able to help with that. Jörn On Fri, Oct 3, 2008 at 5:50 AM, Jeremy Thomerson [EMAIL PROTECTED] wrote: I've been thinking of trying to create some behaviors that combine the standard server-side validation with client-side validation. I just wanted to check to see if anyone knew of something like this already started. I don't want to duplicate work already done. Thanks, -- Jeremy Thomerson http://www.wickettraining.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client side validation behaviors - already started?
Okay, this sounds like the validation plugin (I've written) could be
useful: http://bassistance.de/jquery-plugins/jquery-plugin-validation/
You'd add a very small script to the head: $(function() {
$(#formid).validate() });
And then create inline rules based on the validation behaviour. There
are two options for those: Either classes and (custom attributes) or
metadata (which requires an additional plugin). I think
classes/attributes work really well and result in readable HTML,
though depending on the rules in use, it won't validate. For example,
to make an input required and an email address:
input class=required email name=... /
For an optional input with min and max length:
input minlength=5 maxlength=15 /
For an input with min/max value:
input min=5 max=10 /
Those are actually attributes defined by HTLM5
(http://www.whatwg.org/specs/web-apps/current-work/#the-min-and-max-attributes).
I've tried to keep it close to specs where possible and already
existing.
The thing is: generating those classes/attributes with Wicket is
really easy and already works fine in a lot of projects. Let me know
if invalid HTLM isn't acceptable, and I'll detail the alternatives.
Jörn
On Sat, Oct 4, 2008 at 4:39 PM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
Basically, where you would normally call:
Formcomponent.add(IValidator),
You could now add a behavior. In my behavior, on bind I add the server-side
equivalent validator. Then in renderHead, I add some onLoad JS that adds the
component to a JS array of components to be validated on form submit.
Let me get a little more of the basic started, and then I would REALLY
welcome the help! Maybe tomorrow night or Monday I can get a wicketstuff
project started for it...
The help will be great - my JS fu is rusty!
Jeremy Thomerson
http://www.wickettraining.com
-- sent from a wireless device
-Original Message-
From: Jörn Zaefferer =F6rn_Zaefferer _ [EMAIL PROTECTED]
Sent: Saturday, October 04, 2008 5:50 AM
To: users@wicket.apache.org
Subject: Re: Client side validation behaviors - already started?
What approach for client-side validation are you looking for? I may be
able to help with that.
Jörn
On Fri, Oct 3, 2008 at 5:50 AM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
I've been thinking of trying to create some behaviors that combine the
standard server-side validation with client-side validation. I just wanted
to check to see if anyone knew of something like this already started. I
don't want to duplicate work already done.
Thanks,
--
Jeremy Thomerson
http://www.wickettraining.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client side validation behaviors - already started?
Okay, I was able to commit what I had already started on. This is only a few hours work, so it is nowhere near complete. However, I have the basis for the framework, and a replica of all the StringValidator validation done. https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-client-and-server-validation/ Here are the basic features: - By simply replacing formcomponent.add(StringValidator.exactLength(4)) with add(new ClientAndServerExactLengthValidatingBehavior(form, 4)), it will do the client side validation and add the server side IValidator for you. - It is internationalized because it uses all of the same resource keys / messages that the standard Wicket validators use. - It can insert feedback messages onto the page in a feedback panel or other WebMarkupContainer by calling feedbackpanel.add(new ClientAndServerValidatingFeedbackBehavior(form)) - this will make it use the same appearance that the normal feedback panel would generate. I'm sure there is quite a bit of stuff that can be cleaned up, especially in the JS code. For instance, I'm using document.getElementById quite a bit, but I'm not sure if there are some browsers that may not support that. I need to look because I can't remember. Anyway, feedback is welcome! NOTE: I had started it within another project and was testing it there. I have not had time to test it again after I moved it to its own project. Since all I did was move it, add the license info and rename the packages, it should still work, but you know how that goes. -- Jeremy Thomerson http://www.wickettraining.com On Sat, Oct 4, 2008 at 9:39 AM, Jeremy Thomerson [EMAIL PROTECTED]wrote: Basically, where you would normally call: Formcomponent.add(IValidator), You could now add a behavior. In my behavior, on bind I add the server-side equivalent validator. Then in renderHead, I add some onLoad JS that adds the component to a JS array of components to be validated on form submit. Let me get a little more of the basic started, and then I would REALLY welcome the help! Maybe tomorrow night or Monday I can get a wicketstuff project started for it... The help will be great - my JS fu is rusty! Jeremy Thomerson http://www.wickettraining.com -- sent from a wireless device -Original Message- From: Jörn Zaefferer =F6rn_Zaefferer _ [EMAIL PROTECTED] Sent: Saturday, October 04, 2008 5:50 AM To: users@wicket.apache.org Subject: Re: Client side validation behaviors - already started? What approach for client-side validation are you looking for? I may be able to help with that. Jörn On Fri, Oct 3, 2008 at 5:50 AM, Jeremy Thomerson [EMAIL PROTECTED] wrote: I've been thinking of trying to create some behaviors that combine the standard server-side validation with client-side validation. I just wanted to check to see if anyone knew of something like this already started. I don't want to duplicate work already done. Thanks, -- Jeremy Thomerson http://www.wickettraining.com
Re: Pure client side validation
Thanks for that solution,
To summarize that:
- Extend a normal Validator
- Add the IValidatorAddListener Interface
- Implement the onAdded method
- In this method: add a Custom Behavior to the component
- In the custom Behavior: Integrate the js like described here:
http://cwiki.apache.org/WICKET/creating-a-behavior-to-use-a-javascript-library.html
But I think there are two weak points in that implementation (correct me if
I'm wrong):
- I have to rewrite the whole logic für the validator in Javascript (ok,
that's no surprise)
- In case the validator gets an error, I have to do an ajax request to
trigger the wicket feedback message system (a js only feedback would be a
problem, because js validation would produce duplicate messages after a
submit with errors). So in general I only avoid the ajax request if the js
validator finds no errors.
I have some additional questions about this topic:
- Are there any example implementations for such client side validations?
- There is also a Wicket-Stuff project fvalidate: Has this project a
different concept?
- Is there a plan to integrate pure client side validation in the wicket
framework soon?
Harry
igor.vaynberg wrote:
it is possible, just not there out of the box. can look like something
like this
class rangejsvalidator extends rangevalidator implements
IValidatorAddListener {
void onAdded(Component component) { // add some behavior to output
javascript validation }
}
-igor
--
View this message in context:
http://www.nabble.com/Pure-client-side-validation-tp19737383p19774599.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pure client side validation
harrypitt wrote:
Thanks for that solution,
To summarize that:
- Extend a normal Validator
- Add the IValidatorAddListener Interface
- Implement the onAdded method
- In this method: add a Custom Behavior to the component
- In the custom Behavior: Integrate the js like described here:
http://cwiki.apache.org/WICKET/creating-a-behavior-to-use-a-javascript-library.html
But I think there are two weak points in that implementation (correct me if
I'm wrong):
- I have to rewrite the whole logic für the validator in Javascript (ok,
that's no surprise)
- In case the validator gets an error, I have to do an ajax request to
trigger the wicket feedback message system (a js only feedback would be a
problem, because js validation would produce duplicate messages after a
submit with errors). So in general I only avoid the ajax request if the js
validator finds no errors.
I have some additional questions about this topic:
- Are there any example implementations for such client side validations?
- There is also a Wicket-Stuff project fvalidate: Has this project a
different concept?
- Is there a plan to integrate pure client side validation in the wicket
framework soon?
I wont be doing pure client side validation, as it is unsafe..
Harry
igor.vaynberg wrote:
it is possible, just not there out of the box. can look like something
like this
class rangejsvalidator extends rangevalidator implements
IValidatorAddListener {
void onAdded(Component component) { // add some behavior to output
javascript validation }
}
-igor
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pure client side validation
Ok, my question was not clear enough. With Pure client side validation i mean a javascript validation which needs no ajax requests. Of course there should be always a server side validation and the whole default Wicket form-handling AFTER the submit. It would be really stupid to just rely on javascript validation. Nino.Martinez wrote: I wont be doing pure client side validation, as it is unsafe.. -- View this message in context: http://www.nabble.com/Pure-client-side-validation-tp19737383p19777140.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pure client side validation
On Thu, Oct 2, 2008 at 12:33 AM, harrypitt [EMAIL PROTECTED] wrote:
Thanks for that solution,
To summarize that:
- Extend a normal Validator
- Add the IValidatorAddListener Interface
- Implement the onAdded method
- In this method: add a Custom Behavior to the component
- In the custom Behavior: Integrate the js like described here:
http://cwiki.apache.org/WICKET/creating-a-behavior-to-use-a-javascript-library.html
dont know about your last point. it should just output some javascript
that does the validation test and integrates the results into some
javascript error reporting framework you have - simplest of which
would be alert('field foo does not validate');
But I think there are two weak points in that implementation (correct me if
I'm wrong):
- I have to rewrite the whole logic für the validator in Javascript (ok,
that's no surprise)
this is what ajax helps you not to do, but you said you dont want that
so this is the price to pay.
- In case the validator gets an error, I have to do an ajax request to
trigger the wicket feedback message system (a js only feedback would be a
problem, because js validation would produce duplicate messages after a
submit with errors). So in general I only avoid the ajax request if the js
validator finds no errors.
dont really follow you. if there is a validation error you do not
submit the form...your validators can output something like this:
addevent(form, 'onsubmit', function() { if (!test()) { return false; }});
this way if validation fails the onsubmit returns false and the form
is not submitted. addevent() depends on your favorite javascript
library.
I have some additional questions about this topic:
- Are there any example implementations for such client side validations?
dont think so, maybe you can create one
- There is also a Wicket-Stuff project fvalidate: Has this project a
different concept?
i think that project is defunct, fvalidate has been for a while at least.
- Is there a plan to integrate pure client side validation in the wicket
framework soon?
no, not soon. it is something we can consider for 1.5 but first we
need to end of life 1.3 and release 1.4.
-igor
Harry
igor.vaynberg wrote:
it is possible, just not there out of the box. can look like something
like this
class rangejsvalidator extends rangevalidator implements
IValidatorAddListener {
void onAdded(Component component) { // add some behavior to output
javascript validation }
}
-igor
--
View this message in context:
http://www.nabble.com/Pure-client-side-validation-tp19737383p19774599.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pure client side validation
Ahh ok, I get you. So I guess IVisitor would be very good to use here.. Visit every component and put according js validation in there depending on which validator etc... Could be something I would look into at some point.. Maybe the way would be to upgrade the fvalidate integration to current wicket version? harrypitt wrote: Ok, my question was not clear enough. With Pure client side validation i mean a javascript validation which needs no ajax requests. Of course there should be always a server side validation and the whole default Wicket form-handling AFTER the submit. It would be really stupid to just rely on javascript validation. Nino.Martinez wrote: I wont be doing pure client side validation, as it is unsafe.. -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pure client side validation
saw this lib: http://yav.sourceforge.net/ maybe it fits better? Nino Saturnino Martinez Vazquez Wael wrote: Ahh ok, I get you. So I guess IVisitor would be very good to use here.. Visit every component and put according js validation in there depending on which validator etc... Could be something I would look into at some point.. Maybe the way would be to upgrade the fvalidate integration to current wicket version? harrypitt wrote: Ok, my question was not clear enough. With Pure client side validation i mean a javascript validation which needs no ajax requests. Of course there should be always a server side validation and the whole default Wicket form-handling AFTER the submit. It would be really stupid to just rely on javascript validation. Nino.Martinez wrote: I wont be doing pure client side validation, as it is unsafe.. -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Client side validation behaviors - already started?
I've been thinking of trying to create some behaviors that combine the standard server-side validation with client-side validation. I just wanted to check to see if anyone knew of something like this already started. I don't want to duplicate work already done. Thanks, -- Jeremy Thomerson http://www.wickettraining.com
Pure client side validation
Hi, The company I'm working for is evaluating different java-web-frameworks and it seems that Wicket or JSF will be the winner (To be honest, my personal opinion is that Wicket is the far better choice). In this evaluation i have to make sure if the framework supports pure (java script) client side validation. As far as i know Wicket only supports client side validation with ajax requests. This solution is not satisfying for us, because we want to use the framework to create huge forms which are used by many people. And we think it would be a hard job for our servers to process all that requests. My question: Is it possible to create light weight validators (like required validator) that are working with java script and act like normal wicket validators: textField.add(new ClientSideRequiredValidator()); I know that this topic was discussed in the mailing list many times, but i haven't found a real solution for this. Harry -- View this message in context: http://www.nabble.com/Pure-client-side-validation-tp19737383p19737383.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pure client side validation
Hi Harry, Well, it should be possible to create a Behavior taking care of stuff this... e.g. like textField.add(new ClientSideRequiredValidationBehavior(myErrorLabel)); ClientSideRequiredValidationBehavior should override onComponentTag then to add onchange/onblur javascript code to your input field which updates myErrorLabel in case of error (or does something else). You would merely be adding javascript behavior to your input tag then, which would of course not act like normal wicket validators. And you would have to implement validation in javascript manually again, which would cause some redundancy, because there should definitely be server side validation on form submission as you cannot trust the data coming in from a client. Hope this helps... Cheers :) harrypitt wrote: Hi, The company I'm working for is evaluating different java-web-frameworks and it seems that Wicket or JSF will be the winner (To be honest, my personal opinion is that Wicket is the far better choice). In this evaluation i have to make sure if the framework supports pure (java script) client side validation. As far as i know Wicket only supports client side validation with ajax requests. This solution is not satisfying for us, because we want to use the framework to create huge forms which are used by many people. And we think it would be a hard job for our servers to process all that requests. My question: Is it possible to create light weight validators (like required validator) that are working with java script and act like normal wicket validators: textField.add(new ClientSideRequiredValidator()); I know that this topic was discussed in the mailing list many times, but i haven't found a real solution for this. Harry -- View this message in context: http://www.nabble.com/Pure-client-side-validation-tp19737383p19740821.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pure client side validation
it is possible, just not there out of the box. can look like something like this
class rangejsvalidator extends rangevalidator implements IValidatorAddListener {
void onAdded(Component component) { // add some behavior to output
javascript validation }
}
-igor
On Tue, Sep 30, 2008 at 12:28 AM, harrypitt [EMAIL PROTECTED] wrote:
Hi,
The company I'm working for is evaluating different java-web-frameworks and
it seems that Wicket or JSF will be the winner (To be honest, my personal
opinion is that Wicket is the far better choice). In this evaluation i have
to make sure if the framework supports pure (java script) client side
validation.
As far as i know Wicket only supports client side validation with ajax
requests. This solution is not satisfying for us, because we want to use the
framework to create huge forms which are used by many people. And we think
it would be a hard job for our servers to process all that requests.
My question: Is it possible to create light weight validators (like required
validator) that are working with java script and act like normal wicket
validators:
textField.add(new ClientSideRequiredValidator());
I know that this topic was discussed in the mailing list many times, but i
haven't found a real solution for this.
Harry
--
View this message in context:
http://www.nabble.com/Pure-client-side-validation-tp19737383p19737383.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client side validation
Okay, I've attached a patch that adds the maxlength html attribute. On Tue, Jul 1, 2008 at 11:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Tue, Jul 1, 2008 at 7:11 AM, Ryan Sonnek [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client side validation
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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Form} or
[EMAIL PROTECTED] 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 codeComponent/code to which the validator was
just added
*/
void onAdded(Component component);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client side validation
On Tue, Jul 1, 2008 at 7:11 AM, Ryan Sonnek [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client side validation
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 [EMAIL PROTECTED] 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 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client side validation
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 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client side validation
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 [EMAIL PROTECTED] 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 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sent from Gmail for mobile | mobile.google.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client side validation
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client side validation
yes -igor On Tue, Jun 24, 2008 at 2:38 PM, Manuel Corrales [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
client side validation
http://www.jroller.com/wireframe/entry/wicket_client_side_validation I've spent the past couple weeks investigating Wicket's support for client side validation. IMO, using Ajax for validation in Wicket is really amazing. Lots of folks are touting javascript validation right now, but I think Wicket has a definite advantage because the Ajax validation *reuses* all of your server side validation for free! This might be worth mentioning on the feature list somewhere and I'd be interested in any comments. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
out of curiosity, would there be any interest in shipping Wicket with Ajax form validation turned on *by default* instead of developers manually adding the AjaxFormValidatingBehavior? Are there any drawbacks to having this be the default behavior? On Jan 27, 2008 9:00 AM, Ryan Sonnek [EMAIL PROTECTED] wrote: http://www.jroller.com/wireframe/entry/wicket_client_side_validation I've spent the past couple weeks investigating Wicket's support for client side validation. IMO, using Ajax for validation in Wicket is really amazing. Lots of folks are touting javascript validation right now, but I think Wicket has a definite advantage because the Ajax validation *reuses* all of your server side validation for free! This might be worth mentioning on the feature list somewhere and I'd be interested in any comments. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
-1. There are enough companies and projects that can't use or aren't allowed to use JavaScript, which also precludes the default enabling of such functionality. Martijn On 1/27/08, Ryan Sonnek [EMAIL PROTECTED] wrote: out of curiosity, would there be any interest in shipping Wicket with Ajax form validation turned on *by default* instead of developers manually adding the AjaxFormValidatingBehavior? Are there any drawbacks to having this be the default behavior? On Jan 27, 2008 9:00 AM, Ryan Sonnek [EMAIL PROTECTED] wrote: http://www.jroller.com/wireframe/entry/wicket_client_side_validation I've spent the past couple weeks investigating Wicket's support for client side validation. IMO, using Ajax for validation in Wicket is really amazing. Lots of folks are touting javascript validation right now, but I think Wicket has a definite advantage because the Ajax validation *reuses* all of your server side validation for free! This might be worth mentioning on the feature list somewhere and I'd be interested in any comments. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
Re: client side validation
Seriously? there are companies that mandate you can't use javascript? Even if it's done for you and just works? Wow...that's sad, but I hardly think that's the norm and such extremes should not mandate system defaults. Any other arguments against such a default? The reason I'm bringing this up is that Tapestry ships with client side validation turned on by default, and I *really* like using Wicket's Ajax for form validation. Hey...if tapestry can do it... =) On Jan 27, 2008 10:17 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: -1. There are enough companies and projects that can't use or aren't allowed to use JavaScript, which also precludes the default enabling of such functionality. Martijn On 1/27/08, Ryan Sonnek [EMAIL PROTECTED] wrote: out of curiosity, would there be any interest in shipping Wicket with Ajax form validation turned on *by default* instead of developers manually adding the AjaxFormValidatingBehavior? Are there any drawbacks to having this be the default behavior? On Jan 27, 2008 9:00 AM, Ryan Sonnek [EMAIL PROTECTED] wrote: http://www.jroller.com/wireframe/entry/wicket_client_side_validation I've spent the past couple weeks investigating Wicket's support for client side validation. IMO, using Ajax for validation in Wicket is really amazing. Lots of folks are touting javascript validation right now, but I think Wicket has a definite advantage because the Ajax validation *reuses* all of your server side validation for free! This might be worth mentioning on the feature list somewhere and I'd be interested in any comments. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
also -1. it is trivial to do it yourself automatically like you said in your blog. there are plenty of usecases that wont work out of the box. take a common usecase where the label turns red if the field is in error, how do you do that out of the box? -igor On Jan 27, 2008 8:39 AM, Ryan Sonnek [EMAIL PROTECTED] wrote: Seriously? there are companies that mandate you can't use javascript? Even if it's done for you and just works? Wow...that's sad, but I hardly think that's the norm and such extremes should not mandate system defaults. Any other arguments against such a default? The reason I'm bringing this up is that Tapestry ships with client side validation turned on by default, and I *really* like using Wicket's Ajax for form validation. Hey...if tapestry can do it... =) On Jan 27, 2008 10:17 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: -1. There are enough companies and projects that can't use or aren't allowed to use JavaScript, which also precludes the default enabling of such functionality. Martijn On 1/27/08, Ryan Sonnek [EMAIL PROTECTED] wrote: out of curiosity, would there be any interest in shipping Wicket with Ajax form validation turned on *by default* instead of developers manually adding the AjaxFormValidatingBehavior? Are there any drawbacks to having this be the default behavior? On Jan 27, 2008 9:00 AM, Ryan Sonnek [EMAIL PROTECTED] wrote: http://www.jroller.com/wireframe/entry/wicket_client_side_validation I've spent the past couple weeks investigating Wicket's support for client side validation. IMO, using Ajax for validation in Wicket is really amazing. Lots of folks are touting javascript validation right now, but I think Wicket has a definite advantage because the Ajax validation *reuses* all of your server side validation for free! This might be worth mentioning on the feature list somewhere and I'd be interested in any comments. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
On Jan 27, 2008 11:39 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: Almost any government site/application must comply with accessibility rules which often prohibit the use of JavaScript. section 508 compliance does *not* prohibit javascript or Ajax. You just have to be careful how you use ajax for progressive enhancements and that screen readers still work with the basic website. http://www.section508.gov/ Using ajax for form validation definately does not break accessability since you still get the *same behavior* with the full page refresh upon submitting the form. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
True, I guess you could create your own form superclass that does the default behavior you want. On 1/27/08, Igor Vaynberg [EMAIL PROTECTED] wrote: also -1. it is trivial to do it yourself automatically like you said in your blog. there are plenty of usecases that wont work out of the box. take a common usecase where the label turns red if the field is in error, how do you do that out of the box? -igor On Jan 27, 2008 8:39 AM, Ryan Sonnek [EMAIL PROTECTED] wrote: Seriously? there are companies that mandate you can't use javascript? Even if it's done for you and just works? Wow...that's sad, but I hardly think that's the norm and such extremes should not mandate system defaults. Any other arguments against such a default? The reason I'm bringing this up is that Tapestry ships with client side validation turned on by default, and I *really* like using Wicket's Ajax for form validation. Hey...if tapestry can do it... =) On Jan 27, 2008 10:17 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: -1. There are enough companies and projects that can't use or aren't allowed to use JavaScript, which also precludes the default enabling of such functionality. Martijn On 1/27/08, Ryan Sonnek [EMAIL PROTECTED] wrote: out of curiosity, would there be any interest in shipping Wicket with Ajax form validation turned on *by default* instead of developers manually adding the AjaxFormValidatingBehavior? Are there any drawbacks to having this be the default behavior? On Jan 27, 2008 9:00 AM, Ryan Sonnek [EMAIL PROTECTED] wrote: http://www.jroller.com/wireframe/entry/wicket_client_side_validation I've spent the past couple weeks investigating Wicket's support for client side validation. IMO, using Ajax for validation in Wicket is really amazing. Lots of folks are touting javascript validation right now, but I think Wicket has a definite advantage because the Ajax validation *reuses* all of your server side validation for free! This might be worth mentioning on the feature list somewhere and I'd be interested in any comments. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
On Jan 27, 2008 12:07 PM, James Carman [EMAIL PROTECTED] wrote: True, I guess you could create your own form superclass that does the default behavior you want. Yuk...I'd hate to go through my *entire* application and replace org.apache.wicket.Form with com.mysite.MySpecialForm. very messy. that's why global component instanciation listeners were invented. =) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
On Jan 27, 2008 12:04 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: also -1. it is trivial to do it yourself automatically like you said in your blog. there are plenty of usecases that wont work out of the box. take a common usecase where the label turns red if the field is in error, how do you do that out of the box? Umm...where did I say that there are plenty of usecases that don't work out of the box? The out of the box behavior that wicket *could* support today is dynamic updating of the feedback panel. No inline field messaging or css crazyness is needed...for now... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
So, create an IComponentInstantiationListener that looks for Forms and adds the behavior to them. On 1/27/08, Ryan Sonnek [EMAIL PROTECTED] wrote: On Jan 27, 2008 12:07 PM, James Carman [EMAIL PROTECTED] wrote: True, I guess you could create your own form superclass that does the default behavior you want. Yuk...I'd hate to go through my *entire* application and replace org.apache.wicket.Form with com.mysite.MySpecialForm. very messy. that's why global component instanciation listeners were invented. =) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
On Jan 27, 2008 12:15 PM, James Carman [EMAIL PROTECTED] wrote: So, create an IComponentInstantiationListener that looks for Forms and adds the behavior to them. Yep. That's what I posted on my blog. I'm just asking if there's any interest in making this the *default* behavior. When people evaluate wicket for the first time, they are always looking for out of the box functionality. Even though it's trivial customize your application with this behavior, the majority of users WON'T do it because it's not out of the box. I just think it's a cool feature and other frameworks seem to be investigating client side validation... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
but then my app wont work. i add my own ajax behavior that knows how to do all this... so i would have to override some method on the form and tell it not to do its default thing? let me quote someone Yuk...I'd hate to go through my *entire* application and replace org.apache.wicket.Form with com.mysite.MySpecialForm. very messy. :) your default is simply not good - updating feedback panels is rarely enough. also a lot of times users add a feedback panel per form component, so you will needlessly update tens of feedback panels rather then the single one that needs it. not a good default. imho the best default still remains the one that adds no additional functionality that wasnt explicitly asked for. -igor On Jan 27, 2008 10:09 AM, Ryan Sonnek [EMAIL PROTECTED] wrote: On Jan 27, 2008 12:04 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: also -1. it is trivial to do it yourself automatically like you said in your blog. there are plenty of usecases that wont work out of the box. take a common usecase where the label turns red if the field is in error, how do you do that out of the box? Umm...where did I say that there are plenty of usecases that don't work out of the box? The out of the box behavior that wicket *could* support today is dynamic updating of the feedback panel. No inline field messaging or css crazyness is needed...for now... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
What if the Ajax stuff could be turned on globally using the web
application itself? Then, it could be customized on a per-project
basis.
public class HelloWorldApplication extends WebApplication
{
public boolean isAjaxFormValidationEnabled()
{
return true;
}
}
On 1/27/08, Ryan Sonnek [EMAIL PROTECTED] wrote:
Seriously? there are companies that mandate you can't use javascript?
Even if it's done for you and just works?
Wow...that's sad, but I hardly think that's the norm and such extremes
should not mandate system defaults.
Any other arguments against such a default? The reason I'm bringing
this up is that Tapestry ships with client side validation turned on
by default, and I *really* like using Wicket's Ajax for form
validation.
Hey...if tapestry can do it... =)
On Jan 27, 2008 10:17 AM, Martijn Dashorst [EMAIL PROTECTED] wrote:
-1. There are enough companies and projects that can't use or aren't allowed
to use JavaScript, which also precludes the default enabling of such
functionality.
Martijn
On 1/27/08, Ryan Sonnek [EMAIL PROTECTED] wrote:
out of curiosity, would there be any interest in shipping Wicket with
Ajax form validation turned on *by default* instead of developers
manually adding the AjaxFormValidatingBehavior? Are there any
drawbacks to having this be the default behavior?
On Jan 27, 2008 9:00 AM, Ryan Sonnek [EMAIL PROTECTED] wrote:
http://www.jroller.com/wireframe/entry/wicket_client_side_validation
I've spent the past couple weeks investigating Wicket's support for
client side validation. IMO, using Ajax for validation in Wicket is
really amazing. Lots of folks are touting javascript validation
right now, but I think Wicket has a definite advantage because the
Ajax validation *reuses* all of your server side validation for free!
This might be worth mentioning on the feature list somewhere and I'd
be interested in any comments.
Ryan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
Almost any government site/application must comply with accessibility rules which often prohibit the use of JavaScript. And no, we're not going to fall for the Foo did it ploy :) Martijn On 1/27/08, Ryan Sonnek [EMAIL PROTECTED] wrote: Seriously? there are companies that mandate you can't use javascript? Even if it's done for you and just works? Wow...that's sad, but I hardly think that's the norm and such extremes should not mandate system defaults. Any other arguments against such a default? The reason I'm bringing this up is that Tapestry ships with client side validation turned on by default, and I *really* like using Wicket's Ajax for form validation. Hey...if tapestry can do it... =) On Jan 27, 2008 10:17 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: -1. There are enough companies and projects that can't use or aren't allowed to use JavaScript, which also precludes the default enabling of such functionality. Martijn On 1/27/08, Ryan Sonnek [EMAIL PROTECTED] wrote: out of curiosity, would there be any interest in shipping Wicket with Ajax form validation turned on *by default* instead of developers manually adding the AjaxFormValidatingBehavior? Are there any drawbacks to having this be the default behavior? On Jan 27, 2008 9:00 AM, Ryan Sonnek [EMAIL PROTECTED] wrote: http://www.jroller.com/wireframe/entry/wicket_client_side_validation I've spent the past couple weeks investigating Wicket's support for client side validation. IMO, using Ajax for validation in Wicket is really amazing. Lots of folks are touting javascript validation right now, but I think Wicket has a definite advantage because the Ajax validation *reuses* all of your server side validation for free! This might be worth mentioning on the feature list somewhere and I'd be interested in any comments. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
Re: client side validation
On Jan 27, 2008 12:20 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: but then my app wont work. i add my own ajax behavior that knows how to do all this... so i would have to override some method on the form and tell it not to do its default thing? let me quote someone Yuk...I'd hate to go through my *entire* application and replace org.apache.wicket.Form with com.mysite.MySpecialForm. very messy. :) Yes, class extension IS messy. That's the point of using behaviors, correct? No, you wouldn't need to override a method in Form. You'd override a method in Application or ApplicationSettings to set useGlobalAjaxFormValidation on startup, the application would check this setting and attach a component instantiation listener to add this behavior to all forms. your default is simply not good - updating feedback panels is rarely enough. also a lot of times users add a feedback panel per form component, so you will needlessly update tens of feedback panels rather then the single one that needs it. not a good default. If it's such a shitty default, WHY ship the AjaxFormValidatingBehavior with Wicket at all?! What is the preferred way to do this? I *know* there are a million ways to do this, but that shouldn't stop a framework from having good default behavior. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
On Jan 27, 2008 10:35 AM, Ryan Sonnek [EMAIL PROTECTED] wrote: On Jan 27, 2008 12:20 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: but then my app wont work. i add my own ajax behavior that knows how to do all this... so i would have to override some method on the form and tell it not to do its default thing? let me quote someone Yuk...I'd hate to go through my *entire* application and replace org.apache.wicket.Form with com.mysite.MySpecialForm. very messy. :) Yes, class extension IS messy. That's the point of using behaviors, correct? No, you wouldn't need to override a method in Form. You'd override a method in Application or ApplicationSettings to set useGlobalAjaxFormValidation will we also then have useGlobalAjaxComponentReplacement that is enabled by default? cause you know...we could... on startup, the application would check this setting and attach a component instantiation listener to add this behavior to all forms. your default is simply not good - updating feedback panels is rarely enough. also a lot of times users add a feedback panel per form component, so you will needlessly update tens of feedback panels rather then the single one that needs it. not a good default. If it's such a shitty default, WHY ship the AjaxFormValidatingBehavior with Wicket at all?! What is the preferred way to do this? because that class encapsulates the workflow needed to get this done, so users dont have to reinvent the wheel. its there for you to use optionally...if you want. there is really no preferred way to use it because the usecase space for this is huge across all applications. i dont really see anything wrong with rolling your own form subclass, any ide can do a search and replace for you. what next? someone wants their textfields not to trim input globally, so we have to provide a hook for that? I *know* there are a million ways to do this, but that shouldn't stop a framework from having good default behavior. good, so you can see where im coming from when i say what you suggest is not a good default. anyways, feel free to start a vote on this, because i fear this is a kind of thread that can get pretty long without getting anything accomplished... -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
how would specific components opt out? if i have a textarea i am going to add tinymce behavior to, i dont want it to be validated via ajax. i often have validators that hit the database to check for uniquness, etc. since every time i press a key the entire form is reprocessed, it will add quiet a bit of overhead both to my database and to the response time of the ajax - because optimally if the field is standalone only that one field would be validated... -igor On Jan 27, 2008 8:04 AM, Ryan Sonnek [EMAIL PROTECTED] wrote: out of curiosity, would there be any interest in shipping Wicket with Ajax form validation turned on *by default* instead of developers manually adding the AjaxFormValidatingBehavior? Are there any drawbacks to having this be the default behavior? On Jan 27, 2008 9:00 AM, Ryan Sonnek [EMAIL PROTECTED] wrote: http://www.jroller.com/wireframe/entry/wicket_client_side_validation I've spent the past couple weeks investigating Wicket's support for client side validation. IMO, using Ajax for validation in Wicket is really amazing. Lots of folks are touting javascript validation right now, but I think Wicket has a definite advantage because the Ajax validation *reuses* all of your server side validation for free! This might be worth mentioning on the feature list somewhere and I'd be interested in any comments. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
Okay everyone, after re-reading my posts on this thread, I need to take a minute and apologize for my previous comments. They came off very argumentative and that's not what I intended. I was *so* excited to share this idea and I was kind of expecting everyone's response to be more like WOW, this is a *fabulous* idea. =) I really appreciate the comments, and realize it's a bigger topic than I originally thought. I think I'm going to take some time to think this over and maybe write a blog or two on the subject. My original goal was to see something change with Wicket's core, but maybe all that's needed is a wiki article/cookbook for users to walk through. Thanks again, and I'm genuinely sorry if I pissed anyone off. Really! On Jan 27, 2008 12:54 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: how would specific components opt out? if i have a textarea i am going to add tinymce behavior to, i dont want it to be validated via ajax. i often have validators that hit the database to check for uniquness, etc. since every time i press a key the entire form is reprocessed, it will add quiet a bit of overhead both to my database and to the response time of the ajax - because optimally if the field is standalone only that one field would be validated... -igor On Jan 27, 2008 8:04 AM, Ryan Sonnek [EMAIL PROTECTED] wrote: out of curiosity, would there be any interest in shipping Wicket with Ajax form validation turned on *by default* instead of developers manually adding the AjaxFormValidatingBehavior? Are there any drawbacks to having this be the default behavior? On Jan 27, 2008 9:00 AM, Ryan Sonnek [EMAIL PROTECTED] wrote: http://www.jroller.com/wireframe/entry/wicket_client_side_validation I've spent the past couple weeks investigating Wicket's support for client side validation. IMO, using Ajax for validation in Wicket is really amazing. Lots of folks are touting javascript validation right now, but I think Wicket has a definite advantage because the Ajax validation *reuses* all of your server side validation for free! This might be worth mentioning on the feature list somewhere and I'd be interested in any comments. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
Hi Just a thought about client side validation. I have looked at simple validation like maxlength, min length stuff like that. The jQuery validation plugin solves that easily. My idea was to inherit from the corresponding wicket-validator and implement IBehavoir. Then I would be able to generate javascript based on the validator. I would then add my javascript-enabled-validator to the form classes. Would that be a way to go? comments anyone? The problem I see is to get the name attribute from the formcomponent, but I guess I have to look at the Javadoc for wicket /Flemming On Jan 27, 2008 4:00 PM, Ryan Sonnek [EMAIL PROTECTED] wrote: http://www.jroller.com/wireframe/entry/wicket_client_side_validation I've spent the past couple weeks investigating Wicket's support for client side validation. IMO, using Ajax for validation in Wicket is really amazing. Lots of folks are touting javascript validation right now, but I think Wicket has a definite advantage because the Ajax validation *reuses* all of your server side validation for free! This might be worth mentioning on the feature list somewhere and I'd be interested in any comments. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
mixing validators and behaviors has been on our todo list for a while, but we couldnt do it cleanly in 1.3 because it would mean an api break. we will do it for 1.4 as far as getting the name of formcomponent, that is already possible through ibehavior.bind(component) -igor On Jan 27, 2008 12:07 PM, Flemming Boller [EMAIL PROTECTED] wrote: Hi Just a thought about client side validation. I have looked at simple validation like maxlength, min length stuff like that. The jQuery validation plugin solves that easily. My idea was to inherit from the corresponding wicket-validator and implement IBehavoir. Then I would be able to generate javascript based on the validator. I would then add my javascript-enabled-validator to the form classes. Would that be a way to go? comments anyone? The problem I see is to get the name attribute from the formcomponent, but I guess I have to look at the Javadoc for wicket /Flemming On Jan 27, 2008 4:00 PM, Ryan Sonnek [EMAIL PROTECTED] wrote: http://www.jroller.com/wireframe/entry/wicket_client_side_validation I've spent the past couple weeks investigating Wicket's support for client side validation. IMO, using Ajax for validation in Wicket is really amazing. Lots of folks are touting javascript validation right now, but I think Wicket has a definite advantage because the Ajax validation *reuses* all of your server side validation for free! This might be worth mentioning on the feature list somewhere and I'd be interested in any comments. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
Thanks for the info Igor. On Jan 27, 2008 9:33 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: mixing validators and behaviors has been on our todo list for a while, but we couldnt do it cleanly in 1.3 because it would mean an api break. we will do it for 1.4 as far as getting the name of formcomponent, that is already possible through ibehavior.bind(component) -igor On Jan 27, 2008 12:07 PM, Flemming Boller [EMAIL PROTECTED] wrote: Hi Just a thought about client side validation. I have looked at simple validation like maxlength, min length stuff like that. The jQuery validation plugin solves that easily. My idea was to inherit from the corresponding wicket-validator and implement IBehavoir. Then I would be able to generate javascript based on the validator. I would then add my javascript-enabled-validator to the form classes. Would that be a way to go? comments anyone? The problem I see is to get the name attribute from the formcomponent, but I guess I have to look at the Javadoc for wicket /Flemming On Jan 27, 2008 4:00 PM, Ryan Sonnek [EMAIL PROTECTED] wrote: http://www.jroller.com/wireframe/entry/wicket_client_side_validation I've spent the past couple weeks investigating Wicket's support for client side validation. IMO, using Ajax for validation in Wicket is really amazing. Lots of folks are touting javascript validation right now, but I think Wicket has a definite advantage because the Ajax validation *reuses* all of your server side validation for free! This might be worth mentioning on the feature list somewhere and I'd be interested in any comments. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
That doesn't work. Sometimes you want to add multiple behaviors to the same event. Wicket doesn't support that. Erik. James Carman wrote: So, create an IComponentInstantiationListener that looks for Forms and adds the behavior to them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
