[
http://www.stripesframework.org/jira/browse/STS-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12396#comment-12396
]
Iwao AVE! commented on STS-846:
-------------------------------
Hi Samuel,
> I rather go with the 'formatPattern' attribute than with a custom formatter
> that does not bring any additional benefit.
> A double has a significand precision of 53 bits (approximately 16 decimal
> digits) and can easily handle my needs.
> On top of that, the double field is on an external entity which I do not
> control, and I have no desire in wrapping into a custom object or extending
> it.
I thought your concern was about the precision, sorry for my misunderstanding.
Now, you don't need to change the field type from Double to BigDecimal, all you
need is a formatter for Double type.
# You can't get away from formatters regarding this topic, really ;)
> Or why not just forget about any formatter if the user does not fill
> formatType and formatPattern attributes?
> Check if those attributes are missing and change the line 328
> InputTagSupport.java from:
> String formatted = (formatter == null) ? String.valueOf(input) :
> formatter.format(input);
> to
> String formatted = String.valueOf(input);
Abandoning Formatters is not realistic (it does much more than just formatting
numbers).
You should consider extending them to satisfy your requirement.
By creating a simple custom formatter like the following, you can get exactly
the same effect.
public class DoubleFormatter implements Formatter<Double> {
public String format(Double input) {
return String.valueOf(input);
}
... other methods can be empty.
}
It doesn't require any additional configuration.
Just put it in your extension package and the DefaultTypeFormatterFactory uses
it for all the Double/double fields.
> Anyway, you have to admit that having different outputs whether triggering a
> validation error or not is just wrong.
That seems to be the behavior of DefaultPopulationStrategy.
Try using the BeanFirstPopulationStrategy instead.
Regards,
Iwao
> Strange behavior with Double fields
> -----------------------------------
>
> Key: STS-846
> URL: http://www.stripesframework.org/jira/browse/STS-846
> Project: Stripes
> Issue Type: Bug
> Components: Formatting
> Affects Versions: Release 1.5.6
> Reporter: Samuel Santos
> Priority: Critical
>
> I have a strange behavior with fields using the type Double.
> If I submit a form with a double field in it and get a validation error (e.g.
> a different required field that is missing), the input is populated with the
> exact value that I have inserted (e.g. 3.123456789).
> But if I do not trigger a validation error and forward to the same JSP page,
> the input is populated with the right value but trimmed to only 3 decimal
> cases (e.g. 3.123).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
