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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
