You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Mike Kienenberger <mk...@gmail.com> on 2007/11/30 20:17:09 UTC
Re: NumberConverter using buggy NumberFormat ?
Matthias,
This might be related to
http://issues.apache.org/jira/browse/TOMAHAWK-610. See if using this
code as a workaround works for you.
On Nov 30, 2007 1:38 PM, Matthias Wessendorf <ma...@apache.org> wrote:
> Hi Ryan,
>
> I noticed some strange things, when using the NumberConverter for:
> -currency
> -fr_FR locale
>
> I guess it is a bug in the underlying JDK (1.5.0_11 I am using)........
>
> I did a quick JUnit test-case against the MyFaces API (which contains
> the *base* number-converter)
>
> protected void setUp() throws Exception
> {
> super.setUp();
>
> mock = new NumberConverter();
> mock.setLocale(Locale.FRANCE);
> FacesContext.getCurrentInstance().getViewRoot().setLocale(Locale.GERMANY);
> }
>
> public void testFranceLocale()
> {
> UIInput input = new UIInput();
> mock.setType("currency");
> Number number = (Number)
> mock.getAsObject(FacesContext.getCurrentInstance(), input, "12 345,68
> €");
> assertNotNull(number);
> }
>
> And............ it fails :-)
>
> So... what is the work-around?
> I assume it is not to not use fr_FR :-))
>
> Also, a simple Java-test fails and shows why:
>
> Doing this:
>
> String va = "12 345,68 €";
> NumberFormat nf = NumberFormat.getCurrencyInstance(Locale.FRANCE);
> Number n = (Number) nf.parseObject(va);
>
> and you'll see that n is NULL.
>
> Why?
> So, here it is:
> the String va contains two blanks (" "), which are between 2 and 3, and
> between 8 and € as well.
>
> In fr_FR, however, the *grouping separator * is not " ", but it is a
> special char for blank (\u00a0).
> So, my little test will pass, when the first BLANK is replaced by the
> special char...
>
> I thought, that the NumberFormat actually does parse the object for me!!
> Looks like for the "fr_FR" locale, I have to create a *custom parser*...
> Which is odd, IMO
>
> Now, do this:
>
> String va1 = "12 345,68 €";
> NumberFormat nf = NumberFormat.getCurrencyInstance(Locale.FRANCE);
> String va2 = nf.format(12345.68));
> System.out.println(va1.equals(va2));
>
> and you see, what the issue from another side :-)
>
> Any ideas?
> (Or perhaps known bugs?)
>
> Thx,
> Matthias
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help@javaserverfaces.dev.java.net
>
>
Re: NumberConverter using buggy NumberFormat ?
Posted by Mike Kienenberger <mk...@gmail.com>.
Oops.
Correct author (Joe Sam Shirah) but wrong article/code-contribution.
Take a look at this instead:
http://www.ibm.com/developerworks/java/library/j-numberformat/
and see if you can use it to work around the currency parsing issue.
On Nov 30, 2007 2:17 PM, Mike Kienenberger <mk...@gmail.com> wrote:
> Matthias,
>
> This might be related to
> http://issues.apache.org/jira/browse/TOMAHAWK-610. See if using this
> code as a workaround works for you.
>
>
>
> On Nov 30, 2007 1:38 PM, Matthias Wessendorf <ma...@apache.org> wrote:
> > Hi Ryan,
> >
> > I noticed some strange things, when using the NumberConverter for:
> > -currency
> > -fr_FR locale
> >
> > I guess it is a bug in the underlying JDK (1.5.0_11 I am using)........
> >
> > I did a quick JUnit test-case against the MyFaces API (which contains
> > the *base* number-converter)
> >
> > protected void setUp() throws Exception
> > {
> > super.setUp();
> >
> > mock = new NumberConverter();
> > mock.setLocale(Locale.FRANCE);
> > FacesContext.getCurrentInstance().getViewRoot().setLocale(Locale.GERMANY);
> > }
> >
> > public void testFranceLocale()
> > {
> > UIInput input = new UIInput();
> > mock.setType("currency");
> > Number number = (Number)
> > mock.getAsObject(FacesContext.getCurrentInstance(), input, "12 345,68
> > €");
> > assertNotNull(number);
> > }
> >
> > And............ it fails :-)
> >
> > So... what is the work-around?
> > I assume it is not to not use fr_FR :-))
> >
> > Also, a simple Java-test fails and shows why:
> >
> > Doing this:
> >
> > String va = "12 345,68 €";
> > NumberFormat nf = NumberFormat.getCurrencyInstance(Locale.FRANCE);
> > Number n = (Number) nf.parseObject(va);
> >
> > and you'll see that n is NULL.
> >
> > Why?
> > So, here it is:
> > the String va contains two blanks (" "), which are between 2 and 3, and
> > between 8 and € as well.
> >
> > In fr_FR, however, the *grouping separator * is not " ", but it is a
> > special char for blank (\u00a0).
> > So, my little test will pass, when the first BLANK is replaced by the
> > special char...
> >
> > I thought, that the NumberFormat actually does parse the object for me!!
> > Looks like for the "fr_FR" locale, I have to create a *custom parser*...
> > Which is odd, IMO
> >
> > Now, do this:
> >
> > String va1 = "12 345,68 €";
> > NumberFormat nf = NumberFormat.getCurrencyInstance(Locale.FRANCE);
> > String va2 = nf.format(12345.68));
> > System.out.println(va1.equals(va2));
> >
> > and you see, what the issue from another side :-)
> >
> > Any ideas?
> > (Or perhaps known bugs?)
> >
> > Thx,
> > Matthias
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > mail: matzew-at-apache-dot-org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@javaserverfaces.dev.java.net
> > For additional commands, e-mail: dev-help@javaserverfaces.dev.java.net
> >
> >
>