Hi, Nacho, On Apr 11, 2005 2:22 PM, Nacho G. Mac Dowell <[EMAIL PROTECTED]> wrote:
> Now it is the point where you might not like this solution. It is that > all TypeSG would have to use AtomicTypeSG's getCastFromString. That is > IntegerSG, ShortSG, ... I have no problem, if you generalize the getCastFromString for the subclasses of AtomicTypeSG. The only important point is, that this method is indeed used for processing of default values and/or enumerations. (Note, that atomic values aren't the only simple types, there are also ListType and/or UnionType.) The only points I dislike with your solution is, that you'd defer the use of the DatatypeConverter to compile time. Whereever possible, the DatatypeConverter should be used at generation time. I do not know, if this is currently always the case. However, it is the case (for example) in the LongSG. Note the following: If all AtomicTypeSG's do this at generation time, then the ListTypeSG and the UnionTypeSG can do it at generation time as well, by invoking the corresponding atomic SG's. Doing this at generation time is *much* more user friendly. If this isn't possible in the generalized case, I'd see no point in generalization. (However, generalization should still be possible by invoking an abstract method internally, that invokes the datatype converter internally and returns an object.) > PD: We'd also need: (taken from DatatypeConverter) > The JAXB provider is responsible to initialize the DatatypeConverter > class by invoking setDatatypeConverter(DatatypeConverterInterface) as > soon as possible. > Is this being done? Yes. Indeed all datatype conversion at runtime goes through the datatype converter. Besides, you can even replace it as a marshaller and/or unmarshaller property. Jochen -- Outside of a dog, a book is man's best friend. Inside of a dog, its too dark to read. (Groucho Marx) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
