Sure it amounts to *not* making use of our constructor based reflection (ie can we find a constructor that takes a string?). Gabriel recommended a jakarta commons implementation that was more open ended, but we could also roll our own (ends up being something similar to a hibernate "UserType"), basically the glue code to teach geotools about a how to interact with a java class.
The idea is that AttributeType is always pure - and that the implementation of parse( Object ) delegates to a chunk of code that you can teach different temporal decodings, or boolean decodings etc... For the new feature model you could turn that around to handle encodings as well, and store the encoding technique as a client property on the AttributeType itself if needed. Cheers, Jody > Sure, can you jog my memory as to what that is? > > -Justin > > Jody Garnett wrote: > >> Can we look into Gabriel's suggestion for literal parsing? The further >> we move away from TemporalAttributeType.parse( Object ) the better. >> Jody >> >>> Hi all, >>> >>> Currently, TemporalAttributeType just tries the default java date format >>> when trying to parse a date value from a string. I would like to >>> slightly modify this to include a set of "common" date formats to try >>> (including the default). >>> >>> Any objections? >>> >>> -Justin >>> >>> >>> >> !DSPAM:1004,45182f18133641702038478! >> >> > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
