Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mattom@gmx.at designates
 213.165.64.20 as permitted sender)
Message-ID: <43299C93.5060907@gmx.at>
Date: Thu, 15 Sep 2005 18:08:51 +0200
From: Thomas Lutz <mattom@gmx.at>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: [CForms] Bug when converting Doubles and BigDecimals...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi list !

Starting with 
http://www.mail-archive.com/users@cocoon.apache.org/msg29109.html from 
the users list I found a bug (at least I think it is one) in the 
FormattingDecimalConvertor.java.

Setup (code snippets below):
-a form with a field widget that has a datatype decimal (and some 
formatting to make it look pretty)
-a binding that converts from the xml to a decimal
-display the form enter something like: 
12345678901234567890123456789012345678901234567890
-this number is rejected by database validation, because it's to large
-redisplay the form, and, the orginal submitted value has been rounded 
by the convertor to something like 1.2345E60 because

-> in FormattingDecimalConvertor.java the line
decimalFormat.setParseBigDecimal(true);
is missing.

So decimalFormat.parse(value) returns a double, and no BigDecimal, which 
results in "loosing accuracy".

Another thing that could be optimized is that decimalFormat.parse(value) 
is used, and not decimalFormat.parse(value,ParsePosition). If the 
ParsePosition would be compared with the length of value, you could be 
sure that e.g. trailing alphachars would cause an error.

So IMHO something like:

value = value.replace(' ', (char)160);
DecimalFormat decimalFormat = getDecimalFormat(locale, formatCache);
decimalFormat.setParseBigDecimal(true); // NEW
Number decimalValue;

ParsePosition parsePosition = new ParsePosition( 0 );
decimalValue = decimalFormat.parse(value, parsePosition);
// NEW ask for error index and compare lenght instead of catching the 
parsing exception
if ( ( parsePosition.getErrorIndex() != -1 ) || ( 
parsePosition.getIndex() != value.length() ) ) {
  return ConversionResult.create("decimal");
}

would be better.

Shall I supply a patch ? Which other classes should I have a look at ?

regards,
Tom


Code snippets:
Form definition:
<fd:field id="praemieNtoVtg" required="true">
<fd:label>praemieNtoVtg</fd:label>
    <fd:datatype base="decimal">
    <fd:convertor variant="number">
    <fd:patterns>
<fd:pattern>#.00</fd:pattern>
</fd:patterns>
</fd:convertor>
</fd:datatype>
</fd:field>

Form binding:
<fb:value id="praemieNtoVtg" path="field[@name='praemieNtoVtg']">
<fd:convertor datatype="decimal"/>
</fb:value>