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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
