commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [convert] a different approach...
Date Thu, 18 Nov 2004 22:47:27 GMT

On 18 Nov 2004, at 04:57, Matt Sgarlata wrote:

> Hi Ron, Henri, Stephen, others -

(here are some random musing of mine on the concepts but be warned, i 
have looked at the code as yet)

> I haven't been on the list a while but I saw your posts earlier this 
> month.  I too, like Ron, spent some time developing my own approach to 
> the goals of the commons-convert project.  I have some code started 
> out that isn't incredibly well documented, but all the ideas are 
> there.  Below is a summary of my approach.  The code is available at 
> the URL below under the Apache 2.0 license.
>
> http://www.crystalcognition.com/sgarlatm/morph.zip

why not start a little project on source forge...?

> - In place of a registry that tries to 'pick' the right converter, I 
> have the Converters themselves say which objects they can and cannot 
> convert.  The user assembles these converters (programmatically, or 
> via an IoC framework) in whatever order they like into a 
> mega-converter, if you will, that will function more similarly to the 
> ConvertUtils.convert method in BeanUtils.  This 'mega-converter' 
> conforms to the simple Converter interface like every other, 
> 'non-mega' converter.

that sounds like a good approach

> - In place of BeanUtils.copyProperties there is a Copier interface.  
> It is very similar to the Converter interface, but it's original 
> intent was different: to copy data from one location to another, where 
> creating a new object doesn't make sense.  For example, let's say we 
> want to store information from a Map or an object graph as separate 
> attributes in an HTTP request.  We can't just create a new HTTP 
> request object... it already exists!  So we use a Copier.  Basically, 
> Converters are for the simple stuff like primitives, Dates, etc and 
> Copiers are for fancier things like Object[] -> List.  You can always 
> take something that is written with the Copier interface and expose it 
> as a Converter but not vice-versa (The 
> net.sf.morph.converters.CopierConverter class exposes a Copier as a 
> Converter).
> - While working on Copiers, I realized I needed to be able to pull 
> information out of various different types of things: objects and maps 
> are simple examples, but I might also want to be able to pull info 
> from HTTP request parameters, etc.  This is what Reflectors are for.  
> They help Copiers get the job done.

hmmm sounds frameworkish...

> - The Language interface is interesting, but a little out there.  
> Basically once we have Reflectors written, we can easily implement 
> simple languages like the JSTL EL.  The nice thing about how 
> Reflectors are setup though, is that you could easily define a 
> reflector for a DynaBean or for some other arbitrary object type.  
> This lets you extend your Language very easily.

getting the bean query language at the right level of abstraction is key

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message