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
(;/
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
?
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
.
--
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
...@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
/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
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
-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
. 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
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
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
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/
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
-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
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
-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
!
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
/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
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
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
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
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
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 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
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
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 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
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
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,
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
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
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
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
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
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
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
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
[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
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
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
/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
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
? 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
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
?
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
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.
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
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
to be
investigating client side validation...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
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
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
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
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
/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
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
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
: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
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
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.
60 matches
Mail list logo
