Sylvain Wallez dijo: > Antonio Gallardo wrote: > >>Hi: >> >>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: http://jakarta.apache.org/commons/beanutils/api/org/apache/commons/beanutils/converters/package-summary.html I am wondering if this can save us a lot fo work. Even better with "Locale" support: http://jakarta.apache.org/commons/beanutils/api/org/apache/commons/beanutils/locale/converters/package-summary.html 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
