You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Ryan Sonnek <ry...@gmail.com> on 2008/01/27 16:00:03 UTC
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Flemming Boller <fl...@gmail.com>.
Thanks for the info Igor.
On Jan 27, 2008 9:33 PM, Igor Vaynberg <ig...@gmail.com> 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 <fl...@gmail.com>
> 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 <ry...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: client side validation
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <fl...@gmail.com> 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 <ry...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Flemming Boller <fl...@gmail.com>.
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 <ry...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: client side validation
Posted by Ryan Sonnek <ry...@gmail.com>.
On Jan 27, 2008 11:39 AM, Martijn Dashorst <ma...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Martijn Dashorst <ma...@gmail.com>.
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 <ry...@gmail.com> 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 <ma...@gmail.com>
> 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 <ry...@gmail.com> 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 <ry...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> >
> > --
> > 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
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
Posted by James Carman <ja...@carmanconsulting.com>.
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 <ry...@gmail.com> 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 <ma...@gmail.com> 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 <ry...@gmail.com> 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 <ry...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> >
> > --
> > 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Igor Vaynberg <ig...@gmail.com>.
On Jan 27, 2008 10:35 AM, Ryan Sonnek <ry...@gmail.com> wrote:
> On Jan 27, 2008 12:20 PM, Igor Vaynberg <ig...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Ryan Sonnek <ry...@gmail.com>.
On Jan 27, 2008 12:20 PM, Igor Vaynberg <ig...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ry...@gmail.com> wrote:
> On Jan 27, 2008 12:04 PM, Igor Vaynberg <ig...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Ryan Sonnek <ry...@gmail.com>.
On Jan 27, 2008 12:04 PM, Igor Vaynberg <ig...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Ryan Sonnek <ry...@gmail.com>.
On Jan 27, 2008 12:15 PM, James Carman <ja...@carmanconsulting.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Erik van Oosten <e....@grons.nl>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by James Carman <ja...@carmanconsulting.com>.
So, create an IComponentInstantiationListener that looks for Forms and
adds the behavior to them.
On 1/27/08, Ryan Sonnek <ry...@gmail.com> wrote:
> On Jan 27, 2008 12:07 PM, James Carman <ja...@carmanconsulting.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Ryan Sonnek <ry...@gmail.com>.
On Jan 27, 2008 12:07 PM, James Carman <ja...@carmanconsulting.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by James Carman <ja...@carmanconsulting.com>.
True, I guess you could create your own form superclass that does the
default behavior you want.
On 1/27/08, Igor Vaynberg <ig...@gmail.com> 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 <ry...@gmail.com> 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 <ma...@gmail.com> 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 <ry...@gmail.com> 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 <ry...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ry...@gmail.com> 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 <ma...@gmail.com> 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 <ry...@gmail.com> 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 <ry...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> >
> > --
> > 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Ryan Sonnek <ry...@gmail.com>.
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 <ma...@gmail.com> 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 <ry...@gmail.com> 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 <ry...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
> --
> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Martijn Dashorst <ma...@gmail.com>.
-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 <ry...@gmail.com> 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 <ry...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
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
Posted by Ryan Sonnek <ry...@gmail.com>.
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 <ig...@gmail.com> 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 <ry...@gmail.com> 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 <ry...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ry...@gmail.com> 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 <ry...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: client side validation
Posted by Ryan Sonnek <ry...@gmail.com>.
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 <ry...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org