You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Paul Cantrell <ca...@pobox.com> on 2005/12/26 22:45:53 UTC

What gives with number validation?

I have a text field in a form, and I want to make sure that the user  
enters a positive integer into it. I'm utterly befuddled about how to  
accomplish this in a tidy way using Tapestry's new validation system.

Here's my component:

     @Component(
         type="TextField", id="bookQuantity",
         bindings = { "value=ognl:bookQuantity",  
"validators=validators:min=1" } )
     public abstract TextField getBookQuantityComponent();
     public abstract Integer getBookQuantity();
     public abstract void setBookQuantity(Integer value);

If I type a value into this field, I get a ClassCastException at  
Min.java:53:

         Number value = (Number) object;

The object that's being passed in is a string. Clearly the "min"  
validator expects a number to be passed in, but I don't see where my  
string is going to be converted to a number.

The documentation is kind of broken on this front. The TextField docs  
tell me:

     "A TextField may be decorated by the Form's validation delegate,  
but
      does not have a validator, so is limited in editting properties  
types
      beyond string. In most cases, the ValidField component is  
preferred."

And the ValidField docs tell me (under a big red "WARNING" heading):

     "This component has been deprecated; Tapestry 4.0 adds even better
      support for validation to TextField, TextArea and most other for
      element component."

Lovely. The example on the page about validators shows an email  
address, which is of course a string.

I'm sure that this made sense to someone at some point, but that  
person is not me. Surely I'm missing something obvious...?

Cheers,

Paul

_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net



---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: What gives with number validation?

Posted by Jesse Kuhnert <jk...@gmail.com>.
validator: allows you to specify everything together. Ie:
"validator:number,required,minimum=1"

I think having the argument type being inferred is definitely the most ideal
path. I had planed on working on it, but if you feel like rolling up your
sleeves then by all means ;) Just to make it easier for me to apply patches
and validate that they are going well though, it would be doubly ideal if
said changes came with unit tests and if you're feeling especially giving an
updated blurb or two on the validation docs page.

jesse

On 12/26/05, Paul Cantrell <ca...@pobox.com> wrote:
>
> Sorry, I'm lost ... which part of that treatise are you saying
> "validator:" allows? Not specifying a translator?
>
> Any reactions to the rest of it?
>
> P
>
>
> On Dec 26, 2005, at 3:43 PM, Jesse Kuhnert wrote:
>
> > You can still use the validator: binding prefix, which allows what
> > you want.
> > We plan on fixing this at a minimum in 4.1, but it'll probably make
> > its way
> > back out to 4.0 as well.
> >
> > On 12/26/05, Paul Cantrell <ca...@pobox.com> wrote:
> >>
> >> You're right -- adding this binding does the trick:
> >>
> >>      "translator=translator:number"
> >>
> >> It seems wrong that I need to do this, however, since the translation
> >> already happens automatically (and works fine) when it comes time to
> >> actually drop the value into the bookQuantity property (which is
> >> declared as an Integer).
> >>
> >> Something smells bad here -- and it's not just the cruft in the docs.
> >> (Although fixing the docs before the 4.0 release would be a good
> >> idea....) At this point, I have a massive declaration for what should
> >> be a very simple thing, a required positive integer field:
> >>
> >>      @Component(
> >>          type="TextField", id="bookQuantity",
> >>          bindings = {
> >>              "value=ognl:bookQuantity",
> >>              "translator=translator:number",
> >>              "validators=validators:required,min=1" } )
> >>      public abstract TextField getBookQuantityComponent();
> >>      public abstract Integer getBookQuantity();
> >>      public abstract void    setBookQuantity(Integer value);
> >>
> >> Look at how little useful information that mess actually conveys;
> >> look at how many things get repeated:
> >>
> >>         "TextField" : 2x
> >>         The string "[B|b]ookQuantity": 5x
> >>         That fact that the property is a number : 4x (translator,
> >> min,
> >> getter, setter)
> >>
> >> Suppose that:
> >>
> >> (1) there were some default naming conventions for properties named
> >> xxxxComponent being paired with property xxxx,
> >>
> >> (2) the @Component annotation were capable of inferring the type from
> >> the return type of the getter method (why not?), and
> >>
> >> (3) either the min validator parsed strings for itself, or validators
> >> had access to the implicit translation that occurs when populating a
> >> non-String property.
> >>
> >> I would then be able to reduce the annotation above to:
> >>
> >>      @Component( bindings =
> >> { "validators=validators:required,min=1" } )
> >>      public abstract TextField getBookQuantityComponent();
> >>      public abstract Integer getBookQuantity();
> >>      public abstract void setBookQuantity(Integer value);
> >>
> >> If any of ideas 1-3 seem reasonable to others, I would be willing to
> >> work on implementing them....
> >>
> >> Cheers,
> >>
> >> Paul
> >>
> >> On Dec 26, 2005, at 2:56 PM, Jesse Kuhnert wrote:
> >>
> >>> No you're right. This is something I recently discovered as
> >>> well....Unfortunately you'll have to also give it a "translator"
> >>> binding. I
> >>> think int(integer?) is one.
> >>>
> >>> On 12/26/05, Paul Cantrell <ca...@pobox.com> wrote:
> >>>>
> >>>> I have a text field in a form, and I want to make sure that the
> >>>> user
> >>>> enters a positive integer into it. I'm utterly befuddled about
> >>>> how to
> >>>> accomplish this in a tidy way using Tapestry's new validation
> >>>> system.
> >>>>
> >>>> Here's my component:
> >>>>
> >>>>      @Component(
> >>>>          type="TextField", id="bookQuantity",
> >>>>          bindings = { "value=ognl:bookQuantity",
> >>>> "validators=validators:min=1" } )
> >>>>      public abstract TextField getBookQuantityComponent();
> >>>>      public abstract Integer getBookQuantity();
> >>>>      public abstract void setBookQuantity(Integer value);
> >>>>
> >>>> If I type a value into this field, I get a ClassCastException at
> >>>> Min.java:53:
> >>>>
> >>>>          Number value = (Number) object;
> >>>>
> >>>> The object that's being passed in is a string. Clearly the "min"
> >>>> validator expects a number to be passed in, but I don't see
> >>>> where my
> >>>> string is going to be converted to a number.
> >>>>
> >>>> The documentation is kind of broken on this front. The TextField
> >>>> docs
> >>>> tell me:
> >>>>
> >>>>      "A TextField may be decorated by the Form's validation
> >>>> delegate,
> >>>> but
> >>>>       does not have a validator, so is limited in editting
> >>>> properties
> >>>> types
> >>>>       beyond string. In most cases, the ValidField component is
> >>>> preferred."
> >>>>
> >>>> And the ValidField docs tell me (under a big red "WARNING"
> >>>> heading):
> >>>>
> >>>>      "This component has been deprecated; Tapestry 4.0 adds even
> >>>> better
> >>>>       support for validation to TextField, TextArea and most other
> >>>> for
> >>>>       element component."
> >>>>
> >>>> Lovely. The example on the page about validators shows an email
> >>>> address, which is of course a string.
> >>>>
> >>>> I'm sure that this made sense to someone at some point, but that
> >>>> person is not me. Surely I'm missing something obvious...?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Paul
> >>>>
> >>>> _________________________________________________________________
> >>>> Piano music podcast: http://inthehands.com
> >>>> Other interesting stuff: http://innig.net
> >>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> To unsubscribe, e-mail: tapestry-user-
> >>>> unsubscribe@jakarta.apache.org
> >>>> For additional commands, e-mail: tapestry-user-
> >>>> help@jakarta.apache.org
> >>>>
> >>>>
> >>
> >> _________________________________________________________________
> >> Piano music podcast: http://inthehands.com
> >> Other interesting stuff: http://innig.net
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: tapestry-user-
> >> help@jakarta.apache.org
> >>
> >>
>
> _________________________________________________________________
> Piano music podcast: http://inthehands.com
> Other interesting stuff: http://innig.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>

Re: What gives with number validation?

Posted by Paul Cantrell <ca...@pobox.com>.
Sorry, I'm lost ... which part of that treatise are you saying  
"validator:" allows? Not specifying a translator?

Any reactions to the rest of it?

P


On Dec 26, 2005, at 3:43 PM, Jesse Kuhnert wrote:

> You can still use the validator: binding prefix, which allows what  
> you want.
> We plan on fixing this at a minimum in 4.1, but it'll probably make  
> its way
> back out to 4.0 as well.
>
> On 12/26/05, Paul Cantrell <ca...@pobox.com> wrote:
>>
>> You're right -- adding this binding does the trick:
>>
>>      "translator=translator:number"
>>
>> It seems wrong that I need to do this, however, since the translation
>> already happens automatically (and works fine) when it comes time to
>> actually drop the value into the bookQuantity property (which is
>> declared as an Integer).
>>
>> Something smells bad here -- and it's not just the cruft in the docs.
>> (Although fixing the docs before the 4.0 release would be a good
>> idea....) At this point, I have a massive declaration for what should
>> be a very simple thing, a required positive integer field:
>>
>>      @Component(
>>          type="TextField", id="bookQuantity",
>>          bindings = {
>>              "value=ognl:bookQuantity",
>>              "translator=translator:number",
>>              "validators=validators:required,min=1" } )
>>      public abstract TextField getBookQuantityComponent();
>>      public abstract Integer getBookQuantity();
>>      public abstract void    setBookQuantity(Integer value);
>>
>> Look at how little useful information that mess actually conveys;
>> look at how many things get repeated:
>>
>>         "TextField" : 2x
>>         The string "[B|b]ookQuantity": 5x
>>         That fact that the property is a number : 4x (translator,  
>> min,
>> getter, setter)
>>
>> Suppose that:
>>
>> (1) there were some default naming conventions for properties named
>> xxxxComponent being paired with property xxxx,
>>
>> (2) the @Component annotation were capable of inferring the type from
>> the return type of the getter method (why not?), and
>>
>> (3) either the min validator parsed strings for itself, or validators
>> had access to the implicit translation that occurs when populating a
>> non-String property.
>>
>> I would then be able to reduce the annotation above to:
>>
>>      @Component( bindings =  
>> { "validators=validators:required,min=1" } )
>>      public abstract TextField getBookQuantityComponent();
>>      public abstract Integer getBookQuantity();
>>      public abstract void setBookQuantity(Integer value);
>>
>> If any of ideas 1-3 seem reasonable to others, I would be willing to
>> work on implementing them....
>>
>> Cheers,
>>
>> Paul
>>
>> On Dec 26, 2005, at 2:56 PM, Jesse Kuhnert wrote:
>>
>>> No you're right. This is something I recently discovered as
>>> well....Unfortunately you'll have to also give it a "translator"
>>> binding. I
>>> think int(integer?) is one.
>>>
>>> On 12/26/05, Paul Cantrell <ca...@pobox.com> wrote:
>>>>
>>>> I have a text field in a form, and I want to make sure that the  
>>>> user
>>>> enters a positive integer into it. I'm utterly befuddled about  
>>>> how to
>>>> accomplish this in a tidy way using Tapestry's new validation  
>>>> system.
>>>>
>>>> Here's my component:
>>>>
>>>>      @Component(
>>>>          type="TextField", id="bookQuantity",
>>>>          bindings = { "value=ognl:bookQuantity",
>>>> "validators=validators:min=1" } )
>>>>      public abstract TextField getBookQuantityComponent();
>>>>      public abstract Integer getBookQuantity();
>>>>      public abstract void setBookQuantity(Integer value);
>>>>
>>>> If I type a value into this field, I get a ClassCastException at
>>>> Min.java:53:
>>>>
>>>>          Number value = (Number) object;
>>>>
>>>> The object that's being passed in is a string. Clearly the "min"
>>>> validator expects a number to be passed in, but I don't see  
>>>> where my
>>>> string is going to be converted to a number.
>>>>
>>>> The documentation is kind of broken on this front. The TextField  
>>>> docs
>>>> tell me:
>>>>
>>>>      "A TextField may be decorated by the Form's validation  
>>>> delegate,
>>>> but
>>>>       does not have a validator, so is limited in editting  
>>>> properties
>>>> types
>>>>       beyond string. In most cases, the ValidField component is
>>>> preferred."
>>>>
>>>> And the ValidField docs tell me (under a big red "WARNING"  
>>>> heading):
>>>>
>>>>      "This component has been deprecated; Tapestry 4.0 adds even
>>>> better
>>>>       support for validation to TextField, TextArea and most other
>>>> for
>>>>       element component."
>>>>
>>>> Lovely. The example on the page about validators shows an email
>>>> address, which is of course a string.
>>>>
>>>> I'm sure that this made sense to someone at some point, but that
>>>> person is not me. Surely I'm missing something obvious...?
>>>>
>>>> Cheers,
>>>>
>>>> Paul
>>>>
>>>> _________________________________________________________________
>>>> Piano music podcast: http://inthehands.com
>>>> Other interesting stuff: http://innig.net
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------- 
>>>> --
>>>> To unsubscribe, e-mail: tapestry-user- 
>>>> unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: tapestry-user-
>>>> help@jakarta.apache.org
>>>>
>>>>
>>
>> _________________________________________________________________
>> Piano music podcast: http://inthehands.com
>> Other interesting stuff: http://innig.net
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user- 
>> help@jakarta.apache.org
>>
>>

_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net



---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: What gives with number validation?

Posted by Jesse Kuhnert <jk...@gmail.com>.
You can still use the validator: binding prefix, which allows what you want.
We plan on fixing this at a minimum in 4.1, but it'll probably make its way
back out to 4.0 as well.

On 12/26/05, Paul Cantrell <ca...@pobox.com> wrote:
>
> You're right -- adding this binding does the trick:
>
>      "translator=translator:number"
>
> It seems wrong that I need to do this, however, since the translation
> already happens automatically (and works fine) when it comes time to
> actually drop the value into the bookQuantity property (which is
> declared as an Integer).
>
> Something smells bad here -- and it's not just the cruft in the docs.
> (Although fixing the docs before the 4.0 release would be a good
> idea....) At this point, I have a massive declaration for what should
> be a very simple thing, a required positive integer field:
>
>      @Component(
>          type="TextField", id="bookQuantity",
>          bindings = {
>              "value=ognl:bookQuantity",
>              "translator=translator:number",
>              "validators=validators:required,min=1" } )
>      public abstract TextField getBookQuantityComponent();
>      public abstract Integer getBookQuantity();
>      public abstract void    setBookQuantity(Integer value);
>
> Look at how little useful information that mess actually conveys;
> look at how many things get repeated:
>
>         "TextField" : 2x
>         The string "[B|b]ookQuantity": 5x
>         That fact that the property is a number : 4x (translator, min,
> getter, setter)
>
> Suppose that:
>
> (1) there were some default naming conventions for properties named
> xxxxComponent being paired with property xxxx,
>
> (2) the @Component annotation were capable of inferring the type from
> the return type of the getter method (why not?), and
>
> (3) either the min validator parsed strings for itself, or validators
> had access to the implicit translation that occurs when populating a
> non-String property.
>
> I would then be able to reduce the annotation above to:
>
>      @Component( bindings = { "validators=validators:required,min=1" } )
>      public abstract TextField getBookQuantityComponent();
>      public abstract Integer getBookQuantity();
>      public abstract void setBookQuantity(Integer value);
>
> If any of ideas 1-3 seem reasonable to others, I would be willing to
> work on implementing them....
>
> Cheers,
>
> Paul
>
> On Dec 26, 2005, at 2:56 PM, Jesse Kuhnert wrote:
>
> > No you're right. This is something I recently discovered as
> > well....Unfortunately you'll have to also give it a "translator"
> > binding. I
> > think int(integer?) is one.
> >
> > On 12/26/05, Paul Cantrell <ca...@pobox.com> wrote:
> >>
> >> I have a text field in a form, and I want to make sure that the user
> >> enters a positive integer into it. I'm utterly befuddled about how to
> >> accomplish this in a tidy way using Tapestry's new validation system.
> >>
> >> Here's my component:
> >>
> >>      @Component(
> >>          type="TextField", id="bookQuantity",
> >>          bindings = { "value=ognl:bookQuantity",
> >> "validators=validators:min=1" } )
> >>      public abstract TextField getBookQuantityComponent();
> >>      public abstract Integer getBookQuantity();
> >>      public abstract void setBookQuantity(Integer value);
> >>
> >> If I type a value into this field, I get a ClassCastException at
> >> Min.java:53:
> >>
> >>          Number value = (Number) object;
> >>
> >> The object that's being passed in is a string. Clearly the "min"
> >> validator expects a number to be passed in, but I don't see where my
> >> string is going to be converted to a number.
> >>
> >> The documentation is kind of broken on this front. The TextField docs
> >> tell me:
> >>
> >>      "A TextField may be decorated by the Form's validation delegate,
> >> but
> >>       does not have a validator, so is limited in editting properties
> >> types
> >>       beyond string. In most cases, the ValidField component is
> >> preferred."
> >>
> >> And the ValidField docs tell me (under a big red "WARNING" heading):
> >>
> >>      "This component has been deprecated; Tapestry 4.0 adds even
> >> better
> >>       support for validation to TextField, TextArea and most other
> >> for
> >>       element component."
> >>
> >> Lovely. The example on the page about validators shows an email
> >> address, which is of course a string.
> >>
> >> I'm sure that this made sense to someone at some point, but that
> >> person is not me. Surely I'm missing something obvious...?
> >>
> >> Cheers,
> >>
> >> Paul
> >>
> >> _________________________________________________________________
> >> Piano music podcast: http://inthehands.com
> >> Other interesting stuff: http://innig.net
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: tapestry-user-
> >> help@jakarta.apache.org
> >>
> >>
>
> _________________________________________________________________
> Piano music podcast: http://inthehands.com
> Other interesting stuff: http://innig.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>

Re: What gives with number validation?

Posted by Paul Cantrell <ca...@pobox.com>.
You're right -- adding this binding does the trick:

     "translator=translator:number"

It seems wrong that I need to do this, however, since the translation  
already happens automatically (and works fine) when it comes time to  
actually drop the value into the bookQuantity property (which is  
declared as an Integer).

Something smells bad here -- and it's not just the cruft in the docs.  
(Although fixing the docs before the 4.0 release would be a good  
idea....) At this point, I have a massive declaration for what should  
be a very simple thing, a required positive integer field:

     @Component(
         type="TextField", id="bookQuantity",
         bindings = {
             "value=ognl:bookQuantity",
             "translator=translator:number",
             "validators=validators:required,min=1" } )
     public abstract TextField getBookQuantityComponent();
     public abstract Integer getBookQuantity();
     public abstract void    setBookQuantity(Integer value);

Look at how little useful information that mess actually conveys;  
look at how many things get repeated:

	"TextField" : 2x
	The string "[B|b]ookQuantity": 5x
	That fact that the property is a number : 4x (translator, min,  
getter, setter)

Suppose that:

(1) there were some default naming conventions for properties named  
xxxxComponent being paired with property xxxx,

(2) the @Component annotation were capable of inferring the type from  
the return type of the getter method (why not?), and

(3) either the min validator parsed strings for itself, or validators  
had access to the implicit translation that occurs when populating a  
non-String property.

I would then be able to reduce the annotation above to:

     @Component( bindings = { "validators=validators:required,min=1" } )
     public abstract TextField getBookQuantityComponent();
     public abstract Integer getBookQuantity();
     public abstract void setBookQuantity(Integer value);

If any of ideas 1-3 seem reasonable to others, I would be willing to  
work on implementing them....

Cheers,

Paul

On Dec 26, 2005, at 2:56 PM, Jesse Kuhnert wrote:

> No you're right. This is something I recently discovered as
> well....Unfortunately you'll have to also give it a "translator"  
> binding. I
> think int(integer?) is one.
>
> On 12/26/05, Paul Cantrell <ca...@pobox.com> wrote:
>>
>> I have a text field in a form, and I want to make sure that the user
>> enters a positive integer into it. I'm utterly befuddled about how to
>> accomplish this in a tidy way using Tapestry's new validation system.
>>
>> Here's my component:
>>
>>      @Component(
>>          type="TextField", id="bookQuantity",
>>          bindings = { "value=ognl:bookQuantity",
>> "validators=validators:min=1" } )
>>      public abstract TextField getBookQuantityComponent();
>>      public abstract Integer getBookQuantity();
>>      public abstract void setBookQuantity(Integer value);
>>
>> If I type a value into this field, I get a ClassCastException at
>> Min.java:53:
>>
>>          Number value = (Number) object;
>>
>> The object that's being passed in is a string. Clearly the "min"
>> validator expects a number to be passed in, but I don't see where my
>> string is going to be converted to a number.
>>
>> The documentation is kind of broken on this front. The TextField docs
>> tell me:
>>
>>      "A TextField may be decorated by the Form's validation delegate,
>> but
>>       does not have a validator, so is limited in editting properties
>> types
>>       beyond string. In most cases, the ValidField component is
>> preferred."
>>
>> And the ValidField docs tell me (under a big red "WARNING" heading):
>>
>>      "This component has been deprecated; Tapestry 4.0 adds even  
>> better
>>       support for validation to TextField, TextArea and most other  
>> for
>>       element component."
>>
>> Lovely. The example on the page about validators shows an email
>> address, which is of course a string.
>>
>> I'm sure that this made sense to someone at some point, but that
>> person is not me. Surely I'm missing something obvious...?
>>
>> Cheers,
>>
>> Paul
>>
>> _________________________________________________________________
>> Piano music podcast: http://inthehands.com
>> Other interesting stuff: http://innig.net
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user- 
>> help@jakarta.apache.org
>>
>>

_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net



---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: What gives with number validation?

Posted by Jesse Kuhnert <jk...@gmail.com>.
No you're right. This is something I recently discovered as
well....Unfortunately you'll have to also give it a "translator" binding. I
think int(integer?) is one.

On 12/26/05, Paul Cantrell <ca...@pobox.com> wrote:
>
> I have a text field in a form, and I want to make sure that the user
> enters a positive integer into it. I'm utterly befuddled about how to
> accomplish this in a tidy way using Tapestry's new validation system.
>
> Here's my component:
>
>      @Component(
>          type="TextField", id="bookQuantity",
>          bindings = { "value=ognl:bookQuantity",
> "validators=validators:min=1" } )
>      public abstract TextField getBookQuantityComponent();
>      public abstract Integer getBookQuantity();
>      public abstract void setBookQuantity(Integer value);
>
> If I type a value into this field, I get a ClassCastException at
> Min.java:53:
>
>          Number value = (Number) object;
>
> The object that's being passed in is a string. Clearly the "min"
> validator expects a number to be passed in, but I don't see where my
> string is going to be converted to a number.
>
> The documentation is kind of broken on this front. The TextField docs
> tell me:
>
>      "A TextField may be decorated by the Form's validation delegate,
> but
>       does not have a validator, so is limited in editting properties
> types
>       beyond string. In most cases, the ValidField component is
> preferred."
>
> And the ValidField docs tell me (under a big red "WARNING" heading):
>
>      "This component has been deprecated; Tapestry 4.0 adds even better
>       support for validation to TextField, TextArea and most other for
>       element component."
>
> Lovely. The example on the page about validators shows an email
> address, which is of course a string.
>
> I'm sure that this made sense to someone at some point, but that
> person is not me. Surely I'm missing something obvious...?
>
> Cheers,
>
> Paul
>
> _________________________________________________________________
> Piano music podcast: http://inthehands.com
> Other interesting stuff: http://innig.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>