cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: [WOODY] - New short, double and float datatypes
Date Sun, 02 Nov 2003 19:57:23 GMT
Sylvain Wallez dijo:
> Antonio Gallardo wrote:
>>We tought that in some cases we need this datatypes. Currently, they
>> are not implemented in Woody.
>>Can we do that?

> I guess you need this for binding forms to application data?
> So yes we can, but... I've been wondering for some time how to make
> Woody datatypes more tolerant regarding the target binding datatype.
> Defining all these new classes and the associated converters first makes
>  the configuration bigger and second requires the form writer to know
> the  exact range of the numbers it bind to.
> If woody datatypes were more tolerant, we could simply have a "long" and
>  "double" datatypes for numbers, and have them able to accept int, byte,
>  short and float values. These can be considered as secondary value
> types  whose values are accepted by a datatype along with its native
> value type.

This is a good idea. I checked the DynaBeans and (as usual) waste some
time seeing here and there. So in this, I found inside the BeansUtils:

I am wondering if this can save us a lot fo work. Even better with
"Locale" support:

So I think, using this nice converters we can solution all this. As you
suggested we can define subtypes for the users and internal work jut with
some few datatypes (3 - bigdecimal, string and date).

What you think?

Best Regards,

Antonio Gallardo

> Similiarily, we can say that the "date" datatype can accept a secondary
> "long" value type which will avoid defining a "longdate" datatype in the
>  near future...
> For this, I was envisioning two new methods on Datatype:
> - Object normalizeValue(Object): accepts various secondary value types
> as parameter and normalize them to the real type. E.g. an Integer will
> be converted into a Long.
> - Object getValueAs(Object value, Class clazz): converts a value to one
> of the possible secondary value classes allowed for this datatype.
> Note that this doesn't collide with Convertors since these methods act
> on Object values and not on Strings.
> What do you think?
> Sylvain

View raw message