Hi Robert, thanks for your comments : ) My responses are below...
why not start a little project on source forge...?
Already registered on SF this morning... I probably will create a SF project this weekend :) My tentative project name is "Morph".
- 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...
Well yes and no. You are free to implement the Copier interface directly, which is just as simple as the Converter interface (both have 2 very simple methods, isConvertible/isCopiable and convert/copy). Reflectors are getting frameworkish because they are allowing you to plug into the Copiers that come out-of-the-box with Morph. They are basically a mechanism to allow you to treat any "weird" type of object as a regular object that has properties. So they provide a universal API for accessing the "properties" of Objects, Maps, DynaBeans, HttpRequest parameters, HttpRequest attributes, HttpSession attributes, or perhaps even RDBMS schemas or XML DOMs. The problem with BeanUtils.copyProperties, is the types of things that are considered to have properties are fixed. They are Objects, Maps and DynaBeans -- no more, no less.
- 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
I'm not sure I follow... any ideas of things I should take a look at?
- robert
Matt
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
