Re: [Trinidad] NumberConverter and fr_FR locale
According the bug:
http://bugs.sun.com/view_bug.do?bug_id=4510618
it is true for Finish Locale as well.
Which I verified.
-M
On Dec 3, 2007 11:52 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
the code does replace the regular spaces w/ non-braking spaces.
A String like 12 345,68 € contains now two spaces and the code
if (dfs.getGroupingSeparator() == '\u00a0')
value = value.replace(' ', '\u00a0');
replaces them.
Now, the String contains two non-braking spaces.
After that, the Converter parses the String and fails.
It fails because it doesn't expect a non-braking space in front of the
EUR-Symbol (€).
The non-braking space is only expected as the grouping-separator.
So, the Java NumberFormat class, does expect a String with non-braking:
12_345,68
AND a regular space
€
A hack, like:
String value = 12 3456,68;
value = value.replace(' ', '\u00a0');
value += €;
NumberFormat nf = NumberFormat.getCurrencyInstance(Locale.FRANCE);
ParsePosition pp = new ParsePosition(0);
Number n = (Number) nf.parseObject(value, pp);
System.out.println(n);
fixes it.
But, if the initial value does contain the €-symbol, like 12 3456,68
€ it fails:
String value = 12 3456,68 €;
value = value.replace(' ', '\u00a0');
NumberFormat nf = NumberFormat.getCurrencyInstance(Locale.FRANCE);
ParsePosition pp = new ParsePosition(0);
Number n = (Number) nf.parseObject(value, pp);
System.out.println(n);
Greetings,
Matthias
On Nov 30, 2007 8:26 PM, Blake Sullivan [EMAIL PROTECTED] wrote:
Matthias Wessendorf wrote:
Hi Blake,
looks like:
http://bugs.sun.com/view_bug.do?bug_id=6318800
But doesn't Adam replacing the spaces with non-breaking spaces before
passing the string off to the NumberFormatter work around this problem?
Have you stepped through the code to verify that the String that we pass to
the NumberFormatter has no spaces in it?
-- Blake
-Matthias
On Nov 30, 2007 7:25 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Blake,
out of the blue, but perhaps that is a JDK bug?
I am on 1.5.0_11
On Nov 30, 2007 7:14 PM, Blake Sullivan [EMAIL PROTECTED] wrote:
Matthias,
I must be missing something. Adam
org.apache.myfaces.trinidad.convert.NumberConverter.getAsObject() to convert
the spaces that the user might have typed in to the non-breaking spaces that
the NumberFormat expects if the grouping character is a non-breaking space.
tr:inputText value=#{validate.currency}
id=outputText1
tr:convertNumber locale=fr_FR type=currency/
/tr:inputText
The rendered output is 12 345,68 €, which is fine.
When re-submitting this value, you'll see an converter-error-msg, that
the format is wrong.
That is because:
1. the groupingSeparator() in fr_FR is '\u00a0'
2. therefore the between 2 and 3 AND 8 and € is replaced by '\u00a0'.
I don't understand why this fails. Isn't the code Adam added explicitly
designed to make this work, by replacing the spaces with non-breaking spaces
before feeding the String to be converted to the NumberFormat?
-- Blake Sullivan
Matthias Wessendorf wrote:
I looked at this again this morning:
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 to 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 fr_FR) 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 is...
Anyway, anyone that has an idea on that one?
Thx!
Matthias
On Nov 28, 2007 10:51 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
for fixing Trinidad-202 ([1] (was done during incubation)), we added
these lines (and some other)
DecimalFormat df = (DecimalFormat)fmt;
DecimalFormatSymbols dfs = df.getDecimalFormatSymbols();
if (dfs.getGroupingSeparator() == '\u00a0')
value = value.replace(' ', '\u00a0');
So far, so good.
But that causes issues, when running in fr_FR locale, like:
tr:inputText value=#{validate.currency}
id=outputText1
tr:convertNumber locale=fr_FR type=currency/
/tr:inputText
The rendered output is 12 345,68 €, which is fine.
When re-submitting this value, you'll see an converter-error-msg, that
Re: [Trinidad] NumberConverter and fr_FR locale
the code does replace the regular spaces w/ non-braking spaces.
A String like 12 345,68 € contains now two spaces and the code
if (dfs.getGroupingSeparator() == '\u00a0')
value = value.replace(' ', '\u00a0');
replaces them.
Now, the String contains two non-braking spaces.
After that, the Converter parses the String and fails.
It fails because it doesn't expect a non-braking space in front of the
EUR-Symbol (€).
The non-braking space is only expected as the grouping-separator.
So, the Java NumberFormat class, does expect a String with non-braking:
12_345,68
AND a regular space
€
A hack, like:
String value = 12 3456,68;
value = value.replace(' ', '\u00a0');
value += €;
NumberFormat nf = NumberFormat.getCurrencyInstance(Locale.FRANCE);
ParsePosition pp = new ParsePosition(0);
Number n = (Number) nf.parseObject(value, pp);
System.out.println(n);
fixes it.
But, if the initial value does contain the €-symbol, like 12 3456,68
€ it fails:
String value = 12 3456,68 €;
value = value.replace(' ', '\u00a0');
NumberFormat nf = NumberFormat.getCurrencyInstance(Locale.FRANCE);
ParsePosition pp = new ParsePosition(0);
Number n = (Number) nf.parseObject(value, pp);
System.out.println(n);
Greetings,
Matthias
On Nov 30, 2007 8:26 PM, Blake Sullivan [EMAIL PROTECTED] wrote:
Matthias Wessendorf wrote:
Hi Blake,
looks like:
http://bugs.sun.com/view_bug.do?bug_id=6318800
But doesn't Adam replacing the spaces with non-breaking spaces before
passing the string off to the NumberFormatter work around this problem?
Have you stepped through the code to verify that the String that we pass to
the NumberFormatter has no spaces in it?
-- Blake
-Matthias
On Nov 30, 2007 7:25 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Blake,
out of the blue, but perhaps that is a JDK bug?
I am on 1.5.0_11
On Nov 30, 2007 7:14 PM, Blake Sullivan [EMAIL PROTECTED] wrote:
Matthias,
I must be missing something. Adam
org.apache.myfaces.trinidad.convert.NumberConverter.getAsObject() to convert
the spaces that the user might have typed in to the non-breaking spaces that
the NumberFormat expects if the grouping character is a non-breaking space.
tr:inputText value=#{validate.currency}
id=outputText1
tr:convertNumber locale=fr_FR type=currency/
/tr:inputText
The rendered output is 12 345,68 €, which is fine.
When re-submitting this value, you'll see an converter-error-msg, that
the format is wrong.
That is because:
1. the groupingSeparator() in fr_FR is '\u00a0'
2. therefore the between 2 and 3 AND 8 and € is replaced by '\u00a0'.
I don't understand why this fails. Isn't the code Adam added explicitly
designed to make this work, by replacing the spaces with non-breaking spaces
before feeding the String to be converted to the NumberFormat?
-- Blake Sullivan
Matthias Wessendorf wrote:
I looked at this again this morning:
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 to 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 fr_FR) 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 is...
Anyway, anyone that has an idea on that one?
Thx!
Matthias
On Nov 28, 2007 10:51 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
for fixing Trinidad-202 ([1] (was done during incubation)), we added
these lines (and some other)
DecimalFormat df = (DecimalFormat)fmt;
DecimalFormatSymbols dfs = df.getDecimalFormatSymbols();
if (dfs.getGroupingSeparator() == '\u00a0')
value = value.replace(' ', '\u00a0');
So far, so good.
But that causes issues, when running in fr_FR locale, like:
tr:inputText value=#{validate.currency}
id=outputText1
tr:convertNumber locale=fr_FR type=currency/
/tr:inputText
The rendered output is 12 345,68 €, which is fine.
When re-submitting this value, you'll see an converter-error-msg, that
the format is wrong.
That is because:
1. the groupingSeparator() in fr_FR is '\u00a0'
2. therefore the between 2 and 3 AND 8 and € is replaced by '\u00a0'.
the later is the issue, and the conversion fails.
Any ideas ?
-Matthias
[1] https://issues.apache.org/jira/browse/TRINIDAD-202
--
Matthias Wessendorf
further stuff:
blog:
Re: [Trinidad] NumberConverter and fr_FR locale
Blake,
out of the blue, but perhaps that is a JDK bug?
I am on 1.5.0_11
On Nov 30, 2007 7:14 PM, Blake Sullivan [EMAIL PROTECTED] wrote:
Matthias,
I must be missing something. Adam
org.apache.myfaces.trinidad.convert.NumberConverter.getAsObject() to convert
the spaces that the user might have typed in to the non-breaking spaces that
the NumberFormat expects if the grouping character is a non-breaking space.
tr:inputText value=#{validate.currency}
id=outputText1
tr:convertNumber locale=fr_FR type=currency/
/tr:inputText
The rendered output is 12 345,68 €, which is fine.
When re-submitting this value, you'll see an converter-error-msg, that
the format is wrong.
That is because:
1. the groupingSeparator() in fr_FR is '\u00a0'
2. therefore the between 2 and 3 AND 8 and € is replaced by '\u00a0'.
I don't understand why this fails. Isn't the code Adam added explicitly
designed to make this work, by replacing the spaces with non-breaking spaces
before feeding the String to be converted to the NumberFormat?
-- Blake Sullivan
Matthias Wessendorf wrote:
I looked at this again this morning:
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 to 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 fr_FR) 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 is...
Anyway, anyone that has an idea on that one?
Thx!
Matthias
On Nov 28, 2007 10:51 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
for fixing Trinidad-202 ([1] (was done during incubation)), we added
these lines (and some other)
DecimalFormat df = (DecimalFormat)fmt;
DecimalFormatSymbols dfs = df.getDecimalFormatSymbols();
if (dfs.getGroupingSeparator() == '\u00a0')
value = value.replace(' ', '\u00a0');
So far, so good.
But that causes issues, when running in fr_FR locale, like:
tr:inputText value=#{validate.currency}
id=outputText1
tr:convertNumber locale=fr_FR type=currency/
/tr:inputText
The rendered output is 12 345,68 €, which is fine.
When re-submitting this value, you'll see an converter-error-msg, that
the format is wrong.
That is because:
1. the groupingSeparator() in fr_FR is '\u00a0'
2. therefore the between 2 and 3 AND 8 and € is replaced by '\u00a0'.
the later is the issue, and the conversion fails.
Any ideas ?
-Matthias
[1] https://issues.apache.org/jira/browse/TRINIDAD-202
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad] NumberConverter and fr_FR locale
Hi Blake,
looks like:
http://bugs.sun.com/view_bug.do?bug_id=6318800
-Matthias
On Nov 30, 2007 7:25 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Blake,
out of the blue, but perhaps that is a JDK bug?
I am on 1.5.0_11
On Nov 30, 2007 7:14 PM, Blake Sullivan [EMAIL PROTECTED] wrote:
Matthias,
I must be missing something. Adam
org.apache.myfaces.trinidad.convert.NumberConverter.getAsObject() to convert
the spaces that the user might have typed in to the non-breaking spaces that
the NumberFormat expects if the grouping character is a non-breaking space.
tr:inputText value=#{validate.currency}
id=outputText1
tr:convertNumber locale=fr_FR type=currency/
/tr:inputText
The rendered output is 12 345,68 €, which is fine.
When re-submitting this value, you'll see an converter-error-msg, that
the format is wrong.
That is because:
1. the groupingSeparator() in fr_FR is '\u00a0'
2. therefore the between 2 and 3 AND 8 and € is replaced by '\u00a0'.
I don't understand why this fails. Isn't the code Adam added explicitly
designed to make this work, by replacing the spaces with non-breaking spaces
before feeding the String to be converted to the NumberFormat?
-- Blake Sullivan
Matthias Wessendorf wrote:
I looked at this again this morning:
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 to 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 fr_FR) 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 is...
Anyway, anyone that has an idea on that one?
Thx!
Matthias
On Nov 28, 2007 10:51 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
for fixing Trinidad-202 ([1] (was done during incubation)), we added
these lines (and some other)
DecimalFormat df = (DecimalFormat)fmt;
DecimalFormatSymbols dfs = df.getDecimalFormatSymbols();
if (dfs.getGroupingSeparator() == '\u00a0')
value = value.replace(' ', '\u00a0');
So far, so good.
But that causes issues, when running in fr_FR locale, like:
tr:inputText value=#{validate.currency}
id=outputText1
tr:convertNumber locale=fr_FR type=currency/
/tr:inputText
The rendered output is 12 345,68 €, which is fine.
When re-submitting this value, you'll see an converter-error-msg, that
the format is wrong.
That is because:
1. the groupingSeparator() in fr_FR is '\u00a0'
2. therefore the between 2 and 3 AND 8 and € is replaced by '\u00a0'.
the later is the issue, and the conversion fails.
Any ideas ?
-Matthias
[1] https://issues.apache.org/jira/browse/TRINIDAD-202
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad] NumberConverter and fr_FR locale
I looked at this again this morning:
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 to 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 fr_FR) 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 is...
Anyway, anyone that has an idea on that one?
Thx!
Matthias
On Nov 28, 2007 10:51 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
for fixing Trinidad-202 ([1] (was done during incubation)), we added
these lines (and some other)
DecimalFormat df = (DecimalFormat)fmt;
DecimalFormatSymbols dfs = df.getDecimalFormatSymbols();
if (dfs.getGroupingSeparator() == '\u00a0')
value = value.replace(' ', '\u00a0');
So far, so good.
But that causes issues, when running in fr_FR locale, like:
tr:inputText value=#{validate.currency}
id=outputText1
tr:convertNumber locale=fr_FR type=currency/
/tr:inputText
The rendered output is 12 345,68 €, which is fine.
When re-submitting this value, you'll see an converter-error-msg, that
the format is wrong.
That is because:
1. the groupingSeparator() in fr_FR is '\u00a0'
2. therefore the between 2 and 3 AND 8 and € is replaced by '\u00a0'.
the later is the issue, and the conversion fails.
Any ideas ?
-Matthias
[1] https://issues.apache.org/jira/browse/TRINIDAD-202
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad] NumberConverter and fr_FR locale
Matthias Wessendorf wrote:
Hi Blake,
looks like:
http://bugs.sun.com/view_bug.do?bug_id=6318800
But doesn't Adam replacing the spaces with non-breaking spaces before
passing the string off to the NumberFormatter work around this problem?
Have you stepped through the code to verify that the String that we pass
to the NumberFormatter has no spaces in it?
-- Blake
-Matthias
On Nov 30, 2007 7:25 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Blake,
out of the blue, but perhaps that is a JDK bug?
I am on 1.5.0_11
On Nov 30, 2007 7:14 PM, Blake Sullivan [EMAIL PROTECTED] wrote:
Matthias,
I must be missing something. Adam
org.apache.myfaces.trinidad.convert.NumberConverter.getAsObject() to convert
the spaces that the user might have typed in to the non-breaking spaces that
the NumberFormat expects if the grouping character is a non-breaking space.
tr:inputText value=#{validate.currency}
id=outputText1
tr:convertNumber locale=fr_FR type=currency/
/tr:inputText
The rendered output is 12 345,68 €, which is fine.
When re-submitting this value, you'll see an converter-error-msg, that
the format is wrong.
That is because:
1. the groupingSeparator() in fr_FR is '\u00a0'
2. therefore the between 2 and 3 AND 8 and € is replaced by '\u00a0'.
I don't understand why this fails. Isn't the code Adam added explicitly
designed to make this work, by replacing the spaces with non-breaking spaces
before feeding the String to be converted to the NumberFormat?
-- Blake Sullivan
Matthias Wessendorf wrote:
I looked at this again this morning:
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 to 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 fr_FR) 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 is...
Anyway, anyone that has an idea on that one?
Thx!
Matthias
On Nov 28, 2007 10:51 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
for fixing Trinidad-202 ([1] (was done during incubation)), we added
these lines (and some other)
DecimalFormat df = (DecimalFormat)fmt;
DecimalFormatSymbols dfs = df.getDecimalFormatSymbols();
if (dfs.getGroupingSeparator() == '\u00a0')
value = value.replace(' ', '\u00a0');
So far, so good.
But that causes issues, when running in fr_FR locale, like:
tr:inputText value=#{validate.currency}
id=outputText1
tr:convertNumber locale=fr_FR type=currency/
/tr:inputText
The rendered output is 12 345,68 €, which is fine.
When re-submitting this value, you'll see an converter-error-msg, that
the format is wrong.
That is because:
1. the groupingSeparator() in fr_FR is '\u00a0'
2. therefore the between 2 and 3 AND 8 and € is replaced by '\u00a0'.
the later is the issue, and the conversion fails.
Any ideas ?
-Matthias
[1] https://issues.apache.org/jira/browse/TRINIDAD-202
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
France Locale and NumberConverter (was Re: [Trinidad] NumberConverter and fr_FR locale)
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 :-))
thx!
Matthias
On Nov 30, 2007 10:37 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I looked at this again this morning:
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 to 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 fr_FR) 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 is...
Anyway, anyone that has an idea on that one?
Thx!
Matthias
On Nov 28, 2007 10:51 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
for fixing Trinidad-202 ([1] (was done during incubation)), we added
these lines (and some other)
DecimalFormat df = (DecimalFormat)fmt;
DecimalFormatSymbols dfs = df.getDecimalFormatSymbols();
if (dfs.getGroupingSeparator() == '\u00a0')
value = value.replace(' ', '\u00a0');
So far, so good.
But that causes issues, when running in fr_FR locale, like:
tr:inputText value=#{validate.currency}
id=outputText1
tr:convertNumber locale=fr_FR type=currency/
/tr:inputText
The rendered output is 12 345,68 €, which is fine.
When re-submitting this value, you'll see an converter-error-msg, that
the format is wrong.
That is because:
1. the groupingSeparator() in fr_FR is '\u00a0'
2. therefore the between 2 and 3 AND 8 and € is replaced by '\u00a0'.
the later is the issue, and the conversion fails.
Any ideas ?
-Matthias
[1] https://issues.apache.org/jira/browse/TRINIDAD-202
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
[Trinidad] NumberConverter and fr_FR locale
for fixing Trinidad-202 ([1] (was done during incubation)), we added
these lines (and some other)
DecimalFormat df = (DecimalFormat)fmt;
DecimalFormatSymbols dfs = df.getDecimalFormatSymbols();
if (dfs.getGroupingSeparator() == '\u00a0')
value = value.replace(' ', '\u00a0');
So far, so good.
But that causes issues, when running in fr_FR locale, like:
tr:inputText value=#{validate.currency}
id=outputText1
tr:convertNumber locale=fr_FR type=currency/
/tr:inputText
The rendered output is 12 345,68 €, which is fine.
When re-submitting this value, you'll see an converter-error-msg, that
the format is wrong.
That is because:
1. the groupingSeparator() in fr_FR is '\u00a0'
2. therefore the between 2 and 3 AND 8 and € is replaced by '\u00a0'.
the later is the issue, and the conversion fails.
Any ideas ?
-Matthias
[1] https://issues.apache.org/jira/browse/TRINIDAD-202
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
