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

2007-08-08 Thread David Leangen

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]



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

2007-08-08 Thread David Leangen

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]



Re: Custom RequiredValidation message

2007-08-08 Thread Igor Vaynberg
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]