Client Side Validation i18n aware?

[Mario Ivankovits <ma...@ops.co.at>]

Hi Cagatay!
> +				var doubleRegExp = /^(\+|-)?\d*\.?\d*([eE]\d+)?[dD]?$/;
>   
I haven't had a look at all your validation code, though, do it deal
with i18n?
Means, the regexp above allows to have a "." - I guess as fraction
delimiter. But then, this depends on language specific settings.
Can this work with your validator?
Also, can it deal with the thousand's point? e.g. 10.000,27 is a valid
number here.
 

Ciao,
Mario

Re: Client Side Validation i18n aware?

[Mario Ivankovits <ma...@ops.co.at>]

Hi Cagatay!
> Good catch, I was thinking about localization before but I left it for
> later for now. Because it seems like the server side converters like
> javax.faces.FloatConverter or javax.faces.DoubleConverter do not
> handle i18n too. I'm trying to make the client side validation be %100
> compatible with the server side so that's why I leave it for later.
Oh, I understand.
Though, this brings up the question about their (the JSF converter)
usefulness.
Anyway, I mostly use the NumberConverter (sandbox) instead of Float and
DoubleConv and there we have to deal with i18n then.
See you then .... hehe :-)


Ciao,
Mario

Re: Client Side Validation i18n aware?

[Cagatay Civici <ca...@gmail.com>]

Just a quick typo fix:)

as an example Float.valueOf("10,2") everytime even in French locale


as an example Float.valueOf("10,2") "fails" everytime even in French locale

Cagatay

On 3/11/07, Cagatay Civici <ca...@gmail.com> wrote:
>
> Hi Mario,
>
> Good catch, I was thinking about localization before but I left it for
> later for now. Because it seems like the server side converters like
> javax.faces.FloatConverter or javax.faces.DoubleConverter do not handle
> i18n too. I'm trying to make the client side validation be %100 compatible
> with the server side so that's why I leave it for later.
>
> For example javax.faces.FloatConverter uses Float.valueOf(String s) method
> which as far as I know does not consider locale, as an example
> Float.valueOf("10,2") everytime even in French locale. I think we should
> use numberformat in these converters, only after these are fixed I can add
> i18n to the client side:)
>
> So what do you think?
>
> Cheers,
>
> Cagatay
>
> On 3/11/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> >
> > Hi Cagatay!
> > > +                             var doubleRegExp =
> > /^(\+|-)?\d*\.?\d*([eE]\d+)?[dD]?$/;
> > >
> > I haven't had a look at all your validation code, though, do it deal
> > with i18n?
> > Means, the regexp above allows to have a "." - I guess as fraction
> > delimiter. But then, this depends on language specific settings.
> > Can this work with your validator?
> > Also, can it deal with the thousand's point? e.g. 10.000,27 is a valid
> > number here.
> >
> >
> > Ciao,
> > Mario
> >
> >
>

Re: Client Side Validation i18n aware?

[Cagatay Civici <ca...@gmail.com>]

Hi Mario,

Good catch, I was thinking about localization before but I left it for later
for now. Because it seems like the server side converters like
javax.faces.FloatConverter or javax.faces.DoubleConverter do not handle i18n
too. I'm trying to make the client side validation be %100 compatible with
the server side so that's why I leave it for later.

For example javax.faces.FloatConverter uses Float.valueOf(String s) method
which as far as I know does not consider locale, as an example
Float.valueOf("10,2")
everytime even in French locale. I think we should use numberformat in these
converters, only after these are fixed I can add i18n to the client side:)

So what do you think?

Cheers,

Cagatay

On 3/11/07, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi Cagatay!
> > +                             var doubleRegExp =
> /^(\+|-)?\d*\.?\d*([eE]\d+)?[dD]?$/;
> >
> I haven't had a look at all your validation code, though, do it deal
> with i18n?
> Means, the regexp above allows to have a "." - I guess as fraction
> delimiter. But then, this depends on language specific settings.
> Can this work with your validator?
> Also, can it deal with the thousand's point? e.g. 10.000,27 is a valid
> number here.
>
>
> Ciao,
> Mario
>
>