You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by David Leangen <wi...@leangen.net> on 2007/08/09 04:30:50 UTC

Custom "RequiredValidation" message (was: Motivation for having setRequired())

Ok, thanks for the explanation, Igor.

Maybe, then, you can tell me if there is a better way of doing what I'm
doing...

I'm working on customising the required messages for each field. For
example, for a "contact" form, rather than writing:

 - A value for field 'Enter your email' is required
 - A value for field 'Subject' is required
 - A value for field 'Enter your message text below' is required

I prefer to write:

 - Please enter your email address
 - Please enter the subject
 - Please enter your message text

The only reasonable way I could think of doing this was to override the
(deprecated!) RequiredValidator, just so I could write this in my
properties file:

EmailRequiredValidator = Please enter your email address
SubjectRequiredValidator = Please enter the subject
MessageBodyRequiredValidator = Please enter your message text


This works, but:
 1. the parent class is deprecated
 2. from what you write above, it sounds like
    this could cause a lot of processing for
    nothing
 3. I don't like this heavy-handed approach, anyway!


Do you see a better way?


Cheers,
Dave



On Wed, 2007-08-08 at 19:15 -0700, Igor Vaynberg wrote:
> the whole refactor started because validators were doing a lot of repeitive
> stuff.
> 
> for example lets say you have a textfield for a purchase quantity. you add
> three validators to it, requred, min1) and checkinventory.
> 
> min(1) = { if (input==null) return; int i=typeconvertinput(); if (i<1)
> error(); }
> checkinventory() = { if (input==null) return; int i=typeconvert(); if
> (i>getavailable()) error(); }
> 
> what do we notice...
> 
> both validators have input==null check because they will run whether or not
> field is required or not. both validators have to perform typeconversion -
> which is potentially an expensive operation.
> 
> so lets refactor type conversion into the formcomponent. great, but the
> problem is we dont know if we have to convert a "" or not. so we also factor
> out the required check.
> 
> the nice thing about it is that now our validators look like this
> 
> min(1) = { if (i<1) error(); }
> checkinventory() = { if (i>getavailable()) error(); }
> 
> so now not every validator has to check for null, and type conversion is
> only performed/checked once and in a single place.
> 
> -igor
> 
> On 8/8/07, David Leangen <wi...@leangen.net> wrote:
> >
> >
> > I guess this was already discussed at some point on the dev list, but I
> > couldn't find the thread.
> >
> > I'm just very curious about the motivation of deprecating
> > RequiredValidator in favour of the setRequired method.
> >
> > Knowing how clever you devs are, I'm sure there's a good reason, but at
> > first glace, to me the RequiredValidator seems like a more elegant
> > solution...
> >
> >
> > Would somebody mind explaining this decision, if you have the time?
> >
> >
> > Thanks!
> > Dave
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: Custom "RequiredValidation" message

Posted by Igor Vaynberg <ig...@gmail.com>.
afaik they .properties can be attached to any container with associated
markup: so page/panel/border should work
furthermore you can move them up to the application.properties which is a
global file.

-igor


On 8/8/07, David Leangen <wi...@leangen.net> wrote:
>
>
> > if you want total control you can put this
> > in the .properties of the page with the form
> >
> > formid.email.Required=Enter your email
> > formid.subject.Requried=Subject is required
>
> Is it not possible to put this in the properties file for the component?
> I.e.:
>
> // Constructor for Page
> public MyPage( String id )
> {
>   add( new MyForm( "myForm" );
> }
>
> // Constructor for Form
> public MyForm( String id )
> {
>   add( new MyComponent( "myComponent" );
> }
>
> So in the properties file MyComponent.properties:
>
> email.Required=Enter your email
> subject.Requried=Enter the subject
>
>
> Or are the two ways you described in your last message the only ways to
> possibly resolve customised messages (unless, I suppose, if I create my
> own resolver)?
>
> Essentially, I would like to have finer-grained control over my
> validation messages, but not need to have to repeat them for every page.
> So:
>
>   formid.email.Required = blah
>
> requires me to rewrite them for every page, but
>
>   Required = Enter your ${label}
>
> is not really as fine-grained as I'd like it to be.
>
>
>
> Thanks again,
> Dave
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Custom "RequiredValidation" message

Posted by David Leangen <wi...@leangen.net>.
> if you want total control you can put this
> in the .properties of the page with the form
> 
> formid.email.Required=Enter your email
> formid.subject.Requried=Subject is required

Is it not possible to put this in the properties file for the component?
I.e.:

// Constructor for Page
public MyPage( String id )
{
  add( new MyForm( "myForm" );
}

// Constructor for Form
public MyForm( String id )
{
  add( new MyComponent( "myComponent" );
}

So in the properties file MyComponent.properties:

email.Required=Enter your email
subject.Requried=Enter the subject


Or are the two ways you described in your last message the only ways to
possibly resolve customised messages (unless, I suppose, if I create my
own resolver)?

Essentially, I would like to have finer-grained control over my
validation messages, but not need to have to repeat them for every page.
So:

  formid.email.Required = blah

requires me to rewrite them for every page, but

  Required = Enter your ${label}

is not really as fine-grained as I'd like it to be.



Thanks again,
Dave




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Custom "RequiredValidation" message (was: Motivation for having setRequired())

Posted by David Leangen <wi...@leangen.net>.
Ok, that's much nicer than my way.

Thank you!



On Wed, 2007-08-08 at 20:00 -0700, Igor Vaynberg wrote:
> there are two ways you can do it. if you want total control you can put this
> in the .properties of the page with the form
> 
> formid.email.Required=Enter your email
> formid.subject.Requried=Subject is required
> 
> if you want some structured way you can use formcomponent.setlabel
> 
> email.setlabel(new model("email"));
> subject.setlabel(new model("subject")); // these are ususally ResourceModels
> that pull the value from .properties file
> 
> then in the .properties
> 
> Required=Enter your ${label}
> 
> this will construct
> 
> Enter your email/Enter your subject messages
> 
> -igor
> 
> 
> 
> 
> On 8/8/07, David Leangen <wi...@leangen.net> wrote:
> >
> >
> > Ok, thanks for the explanation, Igor.
> >
> > Maybe, then, you can tell me if there is a better way of doing what I'm
> > doing...
> >
> > I'm working on customising the required messages for each field. For
> > example, for a "contact" form, rather than writing:
> >
> > - A value for field 'Enter your email' is required
> > - A value for field 'Subject' is required
> > - A value for field 'Enter your message text below' is required
> >
> > I prefer to write:
> >
> > - Please enter your email address
> > - Please enter the subject
> > - Please enter your message text
> >
> > The only reasonable way I could think of doing this was to override the
> > (deprecated!) RequiredValidator, just so I could write this in my
> > properties file:
> >
> > EmailRequiredValidator = Please enter your email address
> > SubjectRequiredValidator = Please enter the subject
> > MessageBodyRequiredValidator = Please enter your message text
> >
> >
> > This works, but:
> > 1. the parent class is deprecated
> > 2. from what you write above, it sounds like
> >     this could cause a lot of processing for
> >     nothing
> > 3. I don't like this heavy-handed approach, anyway!
> >
> >
> > Do you see a better way?
> >
> >
> > Cheers,
> > Dave
> >
> >
> >
> > On Wed, 2007-08-08 at 19:15 -0700, Igor Vaynberg wrote:
> > > the whole refactor started because validators were doing a lot of
> > repeitive
> > > stuff.
> > >
> > > for example lets say you have a textfield for a purchase quantity. you
> > add
> > > three validators to it, requred, min1) and checkinventory.
> > >
> > > min(1) = { if (input==null) return; int i=typeconvertinput(); if (i<1)
> > > error(); }
> > > checkinventory() = { if (input==null) return; int i=typeconvert(); if
> > > (i>getavailable()) error(); }
> > >
> > > what do we notice...
> > >
> > > both validators have input==null check because they will run whether or
> > not
> > > field is required or not. both validators have to perform typeconversion
> > -
> > > which is potentially an expensive operation.
> > >
> > > so lets refactor type conversion into the formcomponent. great, but the
> > > problem is we dont know if we have to convert a "" or not. so we also
> > factor
> > > out the required check.
> > >
> > > the nice thing about it is that now our validators look like this
> > >
> > > min(1) = { if (i<1) error(); }
> > > checkinventory() = { if (i>getavailable()) error(); }
> > >
> > > so now not every validator has to check for null, and type conversion is
> > > only performed/checked once and in a single place.
> > >
> > > -igor
> > >
> > > On 8/8/07, David Leangen <wi...@leangen.net> wrote:
> > > >
> > > >
> > > > I guess this was already discussed at some point on the dev list, but
> > I
> > > > couldn't find the thread.
> > > >
> > > > I'm just very curious about the motivation of deprecating
> > > > RequiredValidator in favour of the setRequired method.
> > > >
> > > > Knowing how clever you devs are, I'm sure there's a good reason, but
> > at
> > > > first glace, to me the RequiredValidator seems like a more elegant
> > > > solution...
> > > >
> > > >
> > > > Would somebody mind explaining this decision, if you have the time?
> > > >
> > > >
> > > > Thanks!
> > > > Dave
> > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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: Custom "RequiredValidation" message (was: Motivation for having setRequired())

Posted by Igor Vaynberg <ig...@gmail.com>.
there are two ways you can do it. if you want total control you can put this
in the .properties of the page with the form

formid.email.Required=Enter your email
formid.subject.Requried=Subject is required

if you want some structured way you can use formcomponent.setlabel

email.setlabel(new model("email"));
subject.setlabel(new model("subject")); // these are ususally ResourceModels
that pull the value from .properties file

then in the .properties

Required=Enter your ${label}

this will construct

Enter your email/Enter your subject messages

-igor




On 8/8/07, David Leangen <wi...@leangen.net> wrote:
>
>
> Ok, thanks for the explanation, Igor.
>
> Maybe, then, you can tell me if there is a better way of doing what I'm
> doing...
>
> I'm working on customising the required messages for each field. For
> example, for a "contact" form, rather than writing:
>
> - A value for field 'Enter your email' is required
> - A value for field 'Subject' is required
> - A value for field 'Enter your message text below' is required
>
> I prefer to write:
>
> - Please enter your email address
> - Please enter the subject
> - Please enter your message text
>
> The only reasonable way I could think of doing this was to override the
> (deprecated!) RequiredValidator, just so I could write this in my
> properties file:
>
> EmailRequiredValidator = Please enter your email address
> SubjectRequiredValidator = Please enter the subject
> MessageBodyRequiredValidator = Please enter your message text
>
>
> This works, but:
> 1. the parent class is deprecated
> 2. from what you write above, it sounds like
>     this could cause a lot of processing for
>     nothing
> 3. I don't like this heavy-handed approach, anyway!
>
>
> Do you see a better way?
>
>
> Cheers,
> Dave
>
>
>
> On Wed, 2007-08-08 at 19:15 -0700, Igor Vaynberg wrote:
> > the whole refactor started because validators were doing a lot of
> repeitive
> > stuff.
> >
> > for example lets say you have a textfield for a purchase quantity. you
> add
> > three validators to it, requred, min1) and checkinventory.
> >
> > min(1) = { if (input==null) return; int i=typeconvertinput(); if (i<1)
> > error(); }
> > checkinventory() = { if (input==null) return; int i=typeconvert(); if
> > (i>getavailable()) error(); }
> >
> > what do we notice...
> >
> > both validators have input==null check because they will run whether or
> not
> > field is required or not. both validators have to perform typeconversion
> -
> > which is potentially an expensive operation.
> >
> > so lets refactor type conversion into the formcomponent. great, but the
> > problem is we dont know if we have to convert a "" or not. so we also
> factor
> > out the required check.
> >
> > the nice thing about it is that now our validators look like this
> >
> > min(1) = { if (i<1) error(); }
> > checkinventory() = { if (i>getavailable()) error(); }
> >
> > so now not every validator has to check for null, and type conversion is
> > only performed/checked once and in a single place.
> >
> > -igor
> >
> > On 8/8/07, David Leangen <wi...@leangen.net> wrote:
> > >
> > >
> > > I guess this was already discussed at some point on the dev list, but
> I
> > > couldn't find the thread.
> > >
> > > I'm just very curious about the motivation of deprecating
> > > RequiredValidator in favour of the setRequired method.
> > >
> > > Knowing how clever you devs are, I'm sure there's a good reason, but
> at
> > > first glace, to me the RequiredValidator seems like a more elegant
> > > solution...
> > >
> > >
> > > Would somebody mind explaining this decision, if you have the time?
> > >
> > >
> > > Thanks!
> > > Dave
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
>
>