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 methods.


Thanks for your answer,

Joerg

Reply via email to