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, 25 Nov 2004 22:33:26 GMT

On 18 Nov 2004, at 23:18, Matt Sgarlata wrote:

> 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".

make sure you add a link to the wiki so everyone can find morph :)

i don't see any real harm announcing releases and stuff on the mailing 
lists though it'd probably be wiser not to phrase any posts so as not 
raise the temperature unnecessary. (it's a temptation when you're the 
new project on the block to push general claims of superiority but 
often it's better to focus on individuality: what the project does 
better)

>>> - 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.

that's true enough.

there's nothing wrong with frameworks but IMHO it's important to stop 
good libraries becoming poor frameworks. your reasoning seems sound 
enough and so i'd say that there's space for a framework...

>>> - 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?

JSTL (see EL), JEXL, XPath, velocity, jelly (and many, many more 
projects) all contain bean query languages. there are a lot of 
different approaches. one of the real pains with beanutils is that the  
bean query language is deeply embedded in the component and cannot be 
easily changed. it became clear whilst working on beanutils that really 
one bean query language (no matter how good) really isn't suitable for 
all use cases.

the key is getting the right level of abstraction for the bean query 
language: close enough to take advantage of features in the 
introspection layer but abstract enough to allow radically different 
query languages to be used.

- 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