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 05:00:23 UTC

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

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