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?
Yep. > > 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. > > 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? Good idea. I thought about that because the abstract class: java.lang.Number is the parent of BigDecimal, BigInteger, Byte, Double, Float, Integer, Long, Short. Best Regards, Antonio Gallardo
