[jira] [Closed] (ISIS-621) Improve the Wicket viewer's parsing of numbers

["Dan Haywood (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ISIS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Haywood closed ISIS-621.
----------------------------


> 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.2#6252)