[
https://issues.apache.org/jira/browse/ISIS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840149#comment-13840149
]
ASF subversion and git services commented on ISIS-621:
------------------------------------------------------
Commit c3d8ca29bf27148e3e03a79b00820103099da6a6 in branch refs/heads/master
from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=c3d8ca2 ]
ISIS-621: further improvements to BigDecimal parsing
* prohibit grouping (thousands) separator when enter value
* render thousands separator in view mode
* show decimal places up to scale (eg 123.40 for scale=2)
Implementation notes:
* JavaMathBigDecimalPanelFactory now caches BigDecimalConverterWithScale per
scale,
since each will have different behaviour but is still safe to
be shared across threads.
> 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)
