Re: JCR mapping - step 2

[Christophe Lombart]

Oliver Kiessler wrote:
I commited a small prototype (basic foundation to work together) for the
JCR mapping framework. See in the jcr-mapping subproject.
Currently, it works like this :
* There is a converter class/cms object registered in a config file (see
a example in jcr-mapping\src\conf\convertertest\converters.xml). This
config file is very simple for this prototype.
* A simple converter class can be found in
org.apache.portals.graffito.jcr.testconverter.
* It is possible to use custom JCR nodetypes or unstructured nodes.
This prototype is based on a node type called "graffito:folder"
* Check the
jcr-mapping/src/test/org/apache/portals/graffito/jcr/session/impl/JcrSessionTest.java
<cid:[EMAIL PROTECTED]>to get more info
What about the next step  ? I think the following steps should be
interesting :
* Add search capabilities
* More unit tests
* Build a more generic converter class. I'm thinking about a more
advanced config file.  Something like :
<converters>
   <converter class="org.mycmsframework.Folder"
converterClass="org.apache.portals.graffito.jcr.converter.GenericConverter"
nodetype="graffito:folder" >
            <attributes>
                  <attribute name="description" />
                        <propertyNode name="graffito:description" />
                  </attribute>
            <attributes>
            ....
            <!-- add associations here -->
    <converter>
</converters>
* Any volonteer to continue this work ? Again, the code is still a
*prototype* and you are welcome to send us patches, comments, new
enhancements, ...  I'm going to create a new component in JIRA.
   

some comments after review:
- I am not so sure if having a nodetype "graffito:folder" extending
"nt:folder" is such a good idea. Any subnode must then be a node of
type "nt:hierarchyNode" which I think is not very flexible since I can
only use files and resources. I am not a big fan of the "document" and
"file" concept and I would rather change the nodetype
"graffito:folder" to extend "nt:base".
 

No problem at all - it is just there for the prototype but I think the 
framework should give the flexibility to use any kind of node types 
depending on the user requirements and feeling :-)


- Will the jcr-mapping module have  a spring framework integration? If
so, will it have its own bean xml file?
 

I think this framwork should be container independant. Of course, we can 
add some Spring, PicoContainer & Hivemind config files somewhere.


- Is the converters.xml file really necessary? In theory only a
graffito ContentNode type to jcr nodetype mapping is necessary (if
even that.....)
 

It should be nice to run this framework outside Graffito (I mean in 
other CMS tools requiring a JCR support).
As I explained in my  last mail, this config file can be more complex. 
We can precise the desired node type and for each bean attributes the 
associated property name or subnode reference.
By this way, one generic converter can be used for a lot of beans.

- Will there be a content store integration like the OJB one?
 

Yes. This subproject/framework will be used in an JCR implementation for 
the ContentStore interface.

- Will versioning be an issue? Apart from folders I think versioning
should be implemented by default on any object update.
 

Not yet thinking about that. In my point of view, some objects doesn't 
require versionning and other will do.
This framework should give this kind of flexibility like JCR do.

- Is it because it is a prototype that the API differs so much from
OJB implementation in org.apache.portals.graffito.store.impl.ojb?
 

This is just a small proposal. This is certainly not the last version.
I think this subproject should be complemetly independant of the 
Graffito core components. Don't be inspired by the Graffito API.
We will see later if the Graffito persistence layer require some 
refactoring.


regards,
oliver
p.s. btw, nice job for a quick prototype!
 

Thanks - Thanks to you for your contribution.
Christophe