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
registration
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
describe
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
variables.
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.
Thanks,
Christophe
Regards,
Sandro
