in fact, shale's converter converts my 12345 number to "123.45" string...
but this is the normal behaviour.. my locale's grouping character used while
generating string value from integer value... this is same as jsf ri
converter's behaviour... Issue raiser is C-V's GenericTypeValidator not
concerning default locale while validating "123.45" string value...
GenericTypeValidator has two formatInt method:
1- formatInt(String value) : no locale specified.. so it works as "return
new Integer(value);"
2- formatInt(String value, Locale locale) : uses provided locale while
formatting value. if locale is not provided, uses default locale to format
the value...
integer validator uses the 1. method.. as a result it throws a
numberformatexception at line "return new Integer(value);" (value="123.45
")..
if 1.method use the 2. method with null locale parameter.. it would format
my value according to the default locale and there would be no problem...
my solutioun: 1. method should use 2.method with null locale parameter
instead of "new Integer(value)" conversion....
hope i've cleared the issue....
regards,
hasan..
On 3/1/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 2/28/07, Niall Pemberton <[EMAIL PROTECTED]> 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.
>
Actually, Niall, there are C-V related issues here. Even in the US
locale, the Commons Validator default formatting methods will convert
an integer 1234 into string "1,234", but the C-V validator routine
will not accept that as a valid integer string on a subsequent form
post -- it only wants "1234". I haven't had time to nail down the
precise boundaries of the problem, but there is definitely a C-V
related problem here. It should generate string values that are
accepted by a subsequent validation (especially in the case where the
user did not actually change the value).
> Niall
>
Craig
> On 2/28/07, Hasan Turksoy <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
