[
https://issues.apache.org/jira/browse/ISIS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840160#comment-13840160
]
Martin Grigorov commented on ISIS-621:
--------------------------------------
The code for creating a ValidationError is at
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/markup/html/form/FormComponent.java?source=c#L1219
As you can see the cause's message is not used :-/
The problem is:
ValidationError error = new ValidationError();
it should be:
ValidationError error = new ValidationError(cause.getMessage());
Later at
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/validation/ValidationError.java?source=c#L241
Wicket will look for i18n keys and fallback to the message.
Please file a ticket.
P.S. Do you think BigIntegerConverter is needed by default ?
I've never needed to use it personally and it seems no one asked for it so far.
I see there is BigDecimalConverter though.
I think it is a good idea to add it.
> 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)
