commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: [validator] intRange(between 0-100) validation fails for 1234 value because of a locale issue
Date Thu, 01 Mar 2007 12:34:42 GMT
On 3/1/07, Hasan Turksoy <hturksoy@gmail.com> wrote:
> i can not understand why is this a shale issue.. let me explain it clearly..
> then,, if you still think it as a shale issue, no problem...

Only that it was my initial impression that it was a consequence of
how Shale was using Commons Validator and as I'm not that familiar
(I've had brief looks at Shale) with Shale I thought it more likely
you would get an answer there from Shale Developers - I didn't expect
Craig to post here - but since he has then here is fine :-)

> i'm using shale's integer converter (
> org.apache.shale.validator.converter.IntegerConverter)... it converts my
> 12345 number as normal... i mean,, converting 12345 to "123.45" string is a
> normal behaviour...
> disappointing point is; intRange validator uses GenericValidator (of
> commons-validator.jar),, and it can not understand that string as an integer
> value...

OK I'll take a look and see if I can make sense if it. ATM my initial
impression still holds though - since I believe that Shale's
IntegerConverter is using the new IntegerValidator which is Locale
aware and handles thousand separators - GenericValidator however
origianlly only ever worked for US Locale (locale methods added fairly
recently) and combining the two is going to cause the issue you
describe. All the numeric validators (e.g. IntegerValidator) in the
new "routines" package have "comparison methods" such as isInRange()
(see http://tinyurl.com/24smmq) which are intended to work with the
converted results rather than Strings. So I'm thinking that Shale
should be using these rather than GenericValidator.

Having said that, if Shale works in a similar way to Struts and needs
a static method to configure for things such as integer range
validation then this isn't going to help. As part of Validator 1.4 it
is/was my intention to either switch
GenericValidator/GenericTypeValidator to use the new routines and/or
deprecate those classes and provide a new implementations in the new
package. At the moment thats a bit on hold since my day job is
consuming too many hours at the moment - but its still in my plans.

So where does that leave us - IMO the best solution for Shale would be
if it could take the result from its IntegerConverter (i.e. an
Integer) and validate min/max/range using the new methods on
IntegerValidator. When I get time (which may be a while) I'll try and
understand Shale's implementation to see if this is feasible - unless
one of the Shale devs beats me to it. Whether that is feasible or not
its in my plans to review GenericValidator in light of the new (IMO
improved) functionality we now have in the routines package (see
http://tinyurl.com/cc7a2)

> This means; problem in GenericValidator... it's inside
> commons-validator.jar... so, do you think at which list should we discuss
> this issue?

As I said, I don't mind - especially if we get input from the Shale side here.

Niall

> regards,
>
> hasan...
>
>
> On 2/28/07, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> >
> > This question relates to Shale's validation rather than commons
> > validator - you're more likely to get an answer asking this on their
> > user list.
> >
> > Niall
> >
> > On 2/28/07, Hasan Turksoy <hturksoy@gmail.com> wrote:
> > > hi all,
> > >
> > > i am using an intRange validator together with an integer converter for
> > my
> > > input field.. code is like below;
> > > <h:inputtext value="..myIntField" ...>
> > >  <f:converter converterId="org.apache.shale.converter.Integer" />
> > >  <s:commonsvalidator type="intRange" min="5" max="100" ... />
> > >  <h:inputtext />
> > >
> > > this means; my field will be validated for the 5<->100 range with an
> > integer
> > > value which will be converted by the shale's "
> > > org.apache.shale.validator.converter.IntegerConverter" class...
> > >
> > > issue:
> > > if i enter values less than 1000; validator(GenericValidator class) is
> > > working as expected... But, if i enter values more than 1000, then, it
> > gives
> > > a validation error saying my field's value(1234) must be integer!
> > > This is because when i entered a value like 1234, converter converts my
> > > value to string (validator-rules need string value to make integer
> > > validation) as "123.4".. so, it puts a thousand separator while
> > converting
> > > my value to string... in this case, GenericTypeValidator's "formatInt"
> > > method fails while creating a new Integer from this string... It's
> > trying to
> > > do like;
> > > "return new Integer("123.4");"...
> > >
> > > suggestion:
> > > why this "formatInt(String value)" method of GenericTypeValidator is NOT
> > > using overridden "formatInt(String value, Locale locale);" method with
> > null
> > > locale parameter?.. However, if it did like that; it will use the
> > default
> > > locale while parsing my string to integer... and it will work as
> > expected...
> > >
> > > best regards,
> > >
> > > hasan...

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


Mime
View raw message