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 [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 (i1)
error(); }
checkinventory() = { if (input==null) return; int i=typeconvert(); if
(igetavailable()) 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 (i1) error(); }
checkinventory() = { if (igetavailable()) 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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]