cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [cforms] writing my own data type
Date Wed, 24 Mar 2004 18:33:57 GMT
On 24.03.2004 19:01, Bruno Dumon wrote:

>>I'm trying to write my own data type implementation, but I fail on access
>>restrictions in the AbstractDataType of Woody/Cocoon Forms.
>>I want to have a data type that's based on long and formatted as currency,
>>similar to the one already existing, but
>>1. working:
>>When having
>>  <wd:datatype base="long">
>>    <wd:convertor type="formatting" variant="currency"/>
>>  </wd:datatype>
>>in the form definition I get my amount nicely formatted, but can not save it
>>back. Even a value '123' ends in a ParseException. As I do not want to dive into
>>XReporter I decided to write my own one without XReporter.
> The formatting convertors simply use the java.text.DecimalFormat class
> (the xreporter classes used there are simply a small wrapper to either
> use the JDK version of that class or the one that ships with IBM's ICU4J
> library).

Hmm, strange. This means in general java.text.DecimalFormat returning 
1234567 from the formatted "1.234.567,00 €" should work, shouldn't it?

>>2. and not ignoring cents:
>>When having the long value 1234567 it gets formatted as "1.234.567,00 €",
>>meaning that I can never save cents. It should be "12.345,67 €".
> How can it possibly know that the value you entered should be divided by
> 100?

I did not expected it to work, take a as a hint for improvement, e.g. by 
adding a parameter multiplier. For percent the current behaviour is even 
worse: You can only specify values that are multiples of 100 %.

> Anyway, don't you need only a custom convertor? A long stays a long I
> guess?

Yes, you are right.

>>Back to the actual problem:
>>I extended AbstractDataType and AbstractDataTypeBuilder and copied more or less
>>the LongType and LongTypeBuilder. But I fail at
>>    type.setArrayType(arrayType);
>>    type.setBuilder(this);
>>as these both methods have default access. Is there any specific reason for it?
>>Even passing arrayType and this to the constructor of my AmountType would only
>>work if the methods would have protected access. So what about changing the
>>access of those methods to at least protected, maybe public?
> protected seems good, I don't know why I didn't make them protected.

I will change it. What exactly are these both methods good or needed 
for? I found only selection lists in relation to the field 
AbstractDataType.builder. My own datatype works without calling both 

Thanks for your answer,


View raw message