incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <>
Subject Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Date Wed, 13 Jul 2005 22:21:03 GMT
Hello Christophe,

Christophe Lombart wrote:

>Hi Sandro, 
>Here is my first comments which are similar to Oliver point of view.
>1. I would like to keep the concept of converter class which maximize
>the flexibilty to map to complex type. Anyway, I have to check in more
>details your code.
If your converter would create custom node type structures, than the 
user would require to
register this custom node type structure by themself. The reason is, if 
the mapping
can be defined absolutely free by the user, you cannot create a reusable 
component for the user.
But if you mean something like a proxy to map an object to already 
registered node types,
it should be possible to use the AtomicTypeConverter. But can you please 
a specific mapping scenario as an example? Maybe it is a use case I have 
not yet considered.

In general I would prefer to use many small AtomicTypeConverter 
implementations instead of
some bigger overlapping convertions, because this would improve the 
reusability of the conversions
similar to the idea of the flyweight pattern.

>2. I found JAXB a little bit heavy. There are too many generated
>classes. I think it should be possible to find a easier solution based
>on BeanUtil and/or Digester and/or XmlBean. BeanUtil is quite
>powerfull and simple to use. I think it is a good tools for a
>persistence framework.
Please see my email to Oliver regarding this.

>3.As Oliver suggest, we have to check the JAXB licence ? Maybe Raphaël
>or David can help ?
>4. I'm just wondering what is your mapping strategy ? Is it
>Class<->Item, Attribute<->properties ?
>Maybe I can summarize how I see the mapping (this is a general idea) : 
>1. Instantiate a new POJO from a JCR repo : 
>New Object (instantiate an empty object)
>Get the Mapper object (associeted to the POJO). This Mapper class
>contains all mapping information
>For each Object attributes found in the Mapper class  :
>  A. If the attribute is a primitive type, set the JCR property into
>this attribute. this can be  done with BeanUtil and the JCR API
>  B. If the attribute is an Object (pages, document, content, ... :
>        Get the mapper class for this object type, convert the object
>and assign it to the    attribute. This can be done with BeanUtil and
>the JCR API
>  C.If the attribute is a collection, Map the collection (a loop based
>on the case =B)
>Later, we can try to support proxies and more features like
>auto-retrieve, update, delete, ...
>2. Write a POJO into a JCR mapping
>By using a Mapper class which holds all mapping information (and
>beantuil, and the JCR API), it should be possible to write this object
At the moment I cannot find a big difference of to my implementation 
except the mapping of the
JCR property. I have seen the JCR property like a Java bean property 
which is exposed by
the getter and setter methods of the bean class. If I get your point, 
you see a JCR property
as a local variable of a Java class. This also makes sense in my 
opinion. I think we should
have both mappings. WDYT? I'm not sure if it is possible to get the 
state of private local
BTW: The initial codebase only contains the creation of nodes but not 
yet the creation of objects.

>3. Object Cache
>We can see later how to implement it. 
>So, please before taking a decision and continue your work, check on
>Jakarta Commons. I'm sure there are some tools that can help. If
>needed, I can try to find more time to makes some examples. By this
>way, we can compare both solution and merge all the best found in
>thoses solutions.
Of course I'm open for your improvements.



View raw message