On Mon, Jun 16, 2008 at 6:21 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > On Mon, Jun 16, 2008 at 6:19 PM, Mike Kienenberger <[EMAIL PROTECTED]> wrote: >> Yes, I believe that the sandbox uses Java 1.4. >> >> There's still other pitfalls to avoid with standard java parsing, though: >> >> http://www.ibm.com/developerworks/java/library/j-numberformat/index.html >> >> I thought this was covered in Tomahawk 610, but apparently not. >> Adding a comment about it.
I had to work around something similar already in the past: http://matthiaswessendorf.wordpress.com/2007/12/03/javas-numberformat-bug/ -Matthias > thanks! > -Matthias > >> >> On 6/16/08, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: >>> On Fri, Jun 13, 2008 at 6:04 AM, Mike Kienenberger <[EMAIL PROTECTED]> >>> wrote: >>> >>> > Use the sandbox convertNumber with a BigDecimal type. >>> >>> Ok, >>> I don't use this now. >>> Since Java5 there is a parseBigDecimal() on DecimalFormat. >>> In Trinidad I just turn that guy on. So, that fixes it. >>> >>> Sandbox still still requires Java1.4, right? >>> >>> >>> -matthias >>> >>> >>> >>> > >>> > You may also want to take a few minutes and add the workaround for the >>> > bug in the java currency parser (DecimalFormat) as described in >>> > >>> > http://issues.apache.org/jira/browse/TOMAHAWK-610 >>> > >>> > if it hasn't already been taken care of. >>> > >>> > On 6/13/08, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: >>> >> On Thu, Jun 12, 2008 at 9:55 PM, Leonardo Uribe <[EMAIL PROTECTED]> >>> wrote: >>> >> > BigDecimal converter could solve this problem, maybe this value is >>> converted >>> >> > as double or float as is. >>> >> >>> >> >>> >> ok, the demo was a little bit to simple. >>> >> We want currency formatting etc. Means what the convertNumber actually >>> does. >>> >> >>> >> >>> >> -Matthias >>> >> >>> >> >>> >> > >>> >> > regards >>> >> > >>> >> > Leonardo Uribe >>> >> > >>> >> > On Thu, Jun 12, 2008 at 11:45 PM, Matthias Wessendorf <[EMAIL >>> PROTECTED]> >>> >> > wrote: >>> >> >> >>> >> >> Hi, >>> >> >> >>> >> >> perhaps someone of you knows a workaround for this: >>> >> >> >>> >> >> Take this JSP code: >>> >> >> <h:inputText value="#{bean.number}"> >>> >> >> <f:convertNumber /> >>> >> >> </h:inputText> >>> >> >> >>> >> >> For instance, when the entered value is "333.111" the actual stored >>> >> >> value is 333.1109999999999899955582804977893829345703125 >>> >> >> >>> >> >> I think the mathematic explanation for that in here: >>> >> >> http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems >>> >> >> >>> >> >> My users want to have 333.111 instead of the accurate value... >>> >> >> >>> >> >> Any ideas? >>> >> >> >>> >> >> Thanks! >>> >> >> >>> >> >> -- >>> >> >> Matthias Wessendorf >>> >> >> >>> >> >> further stuff: >>> >> >> blog: http://matthiaswessendorf.wordpress.com/ >>> >> >> sessions: http://www.slideshare.net/mwessendorf >>> >> >> mail: matzew-at-apache-dot-org >>> >> > >>> >> > >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> Matthias Wessendorf >>> >> >>> >> further stuff: >>> >> blog: http://matthiaswessendorf.wordpress.com/ >>> >> sessions: http://www.slideshare.net/mwessendorf >>> >> mail: matzew-at-apache-dot-org >>> >> >>> > >>> >>> >>> >>> >>> -- >>> >>> Matthias Wessendorf >>> >>> further stuff: >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> mail: matzew-at-apache-dot-org >>> >> > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
