[
https://issues.apache.org/jira/browse/ISIS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Haywood updated ISIS-621:
-----------------------------
Description:
1. silently ignores invalidly formatted numbers
Noticed with BigDecimal (but also an issue for other numeric types)...
"When a field is mandatory you can enter anything. There is no check if an
actual value is number being entered.
As an example: when a user enters 100,50 it is not being parsed as number but
no feedback is returned ."
In fact, looking at the code, the Wicket framework provides a bunch of
IConverter implementations, which we should use. (Strangely, there is none for
BigInteger, but can subclass AbstractIntegerConverter).
[ done]
2. Next up, finding that the , (thousands separator) and . (decimal point
separator) are both allowed, but there is opportunity for confusion.
Isis should always use the locale of the end-user (via the HTTP Accept-Language
header), but a European user might not know that, and might assume that the
system was running under En_US. Thus, the user could enter "12.23" (meaning 12
point 23) , and then the system would intrepret this under their local as 1223
(one thousand two hundred and twenty three).
Thus, what we want is for the system to disallow the thousands (grouping)
separator when entering a new value. However, the thousands should still be
rendered when in view mode.
3. Entering two many decimal places should be trapped and flagged as an error.
Currently it throws an exception.
4. When rendering big decimals, should pad with zeros to the required scale.
for example, if the scale is 2, then "123.1" should be rendered as "123.10"
was:
Noticed with BigDecimal (but also an issue for other numeric types)...
"When a field is mandatory you can enter anything. There is no check if an
actual value is number being entered.
As an example: when a user enters 100,50 it is not being parsed as number but
no feedback is returned ."
In fact, looking at the code, the Wicket framework provides a bunch of
IConverter implementations, which we should use. (Strangely, there is none for
BigInteger, but can subclass AbstractIntegerConverter).
> Improve the Wicket viewer's parsing of numbers
> -----------------------------------------------
>
> Key: ISIS-621
> URL: https://issues.apache.org/jira/browse/ISIS-621
> Project: Isis
> Issue Type: Bug
> Components: Viewer: Wicket
> Affects Versions: viewer-wicket-1.3.1
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Priority: Minor
> Fix For: viewer-wicket-1.4.0
>
>
> 1. silently ignores invalidly formatted numbers
> Noticed with BigDecimal (but also an issue for other numeric types)...
> "When a field is mandatory you can enter anything. There is no check if an
> actual value is number being entered.
> As an example: when a user enters 100,50 it is not being parsed as number but
> no feedback is returned ."
> In fact, looking at the code, the Wicket framework provides a bunch of
> IConverter implementations, which we should use. (Strangely, there is none
> for BigInteger, but can subclass AbstractIntegerConverter).
> [ done]
> 2. Next up, finding that the , (thousands separator) and . (decimal point
> separator) are both allowed, but there is opportunity for confusion.
> Isis should always use the locale of the end-user (via the HTTP
> Accept-Language header), but a European user might not know that, and might
> assume that the system was running under En_US. Thus, the user could enter
> "12.23" (meaning 12 point 23) , and then the system would intrepret this
> under their local as 1223 (one thousand two hundred and twenty three).
> Thus, what we want is for the system to disallow the thousands (grouping)
> separator when entering a new value. However, the thousands should still be
> rendered when in view mode.
> 3. Entering two many decimal places should be trapped and flagged as an
> error. Currently it throws an exception.
> 4. When rendering big decimals, should pad with zeros to the required scale.
> for example, if the scale is 2, then "123.1" should be rendered as "123.10"
--
This message was sent by Atlassian JIRA
(v6.1#6144)
