Question

I’m trying save a values’ input field to a BigDecimal. Which already works.
But it produces strange results if I enter decimal deliminator that is not of the locale type.

eg:

class Payment {
   BigDecimal amount;
}

<p:inputText id="amount" value="#{payment.amount}">
  <f:convertNumber locale="en"/>
</p:inputText>
<h:outputText value="#{payment.amount}" />

If I input 10,10
I get: 1,010.00

So the value is taken as 1010
How could I work around this? What am I doing wrong here?

ty

Answer 1

The commas are not significant when parsing an English-locale number. Java’s raw Number types will not retain any formatting information – that’s just presentation data.

The logic for the inputText with a NumberConverter goes like this:

NumberFormat formatter = NumberFormat.getNumberInstance(Locale.ENGLISH);
// NumberConverter turns input string into Number
Number number = formatter.parse("10,10");
// Expression language coerces the Number to BigDecimal
BigDecimal decimal = BigDecimal.valueOf(number.doubleValue());
// On output back to browser:
String output = formatter.format(decimal);
System.out.println(output);

The outputText doesn’t have a converter, so will merely call toString() on its value binding (the BigDecimal.)

I would expect the results to be 1,010 and 1010.0 respectively.

The behavior of NumberConverter is documented in the javadoc. The rules for EL type coercion are documented in JSR 245:

Coerce A to Number type N

• If A is Number, coerce quietly to type N using the following algorithm:
  • If N is BigDecimal,
    • If A is a BigInteger, return new BigDecimal(A)
    • Otherwise, return new BigDecimal(A.doubleValue())

If you want to use the user’s browser locale to interpret number formats, remove the locale attribute. If you want a converter to treat both periods and commas as decimal separators, provide your own Converter implementation.