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: 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]
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]
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]
