incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "LOMBART Christophe" <>
Subject RE: Mapping of Items
Date Tue, 22 Mar 2005 12:41:00 GMT


what about the node type management ? nt:unstructured is used in your framework. Why not to
support other kind of primary node types ?
I'm just wondering when node types becomes important for this kind of mapping.


-----Original Message-----
From:	Oliver Kiessler []
Sent:	Tue 3/22/2005 11:39 AM
Subject:	Re: Mapping of Items
hi sandro,
> the basic idea is, to use the bean class structure as the master and
> create the nodetypes according to the bean classes. E.g it could be
> possible to create the beans out of an uml tool.
> At the moment I can imagine the following use cases:
> a) creating the nodetype structure at design time
> b) reading beans from nodes at runtime
> c) writing beans to nodes at runtime
> d) persist beans to the persistance layer
> e) maintaining the bean structure (rename beans or properties, delete
> beans or properties, change the type of the bean or property...)

I have been using java reflection to analyse class structure at
runtime (b, c, d). The class has to conform to the java bean
specification (private properties, getters and setters). The class has
to have a no-arg constructor and getters and setters. All primitives,
primitive arrays, java bean arrays, collections (Set, Map, List),
hashtables and vectors are currently supported.
> First I would like to create a textual mapping between JCR features and
> Java features like:
> Mixin = Interface
> Node Type Name = Class Name
> isMixin = this.getClass().isInterface()

You should not be using mixins to do this in my mind. Mixins are
special node attributes defining the nature of the *node* (rathing
than the content) used by the JCR implementation (like
mix:referenceable or mix:versionable). You should rather define custom
node types do this if even necessary. The JCR is a CMS infrastructure
that can be persisted in many different ways with exchangeablity and
portability in mind. Using too many custom features may leave you with
a repo that cannot be used by some JCR implementations.

The way I do it, I create a content node at a certain path URI. This
is the top level content node of standard type nt:unstructured
containing a class property of the object that needs to stored. Then a
subnode jcr:content is created. Primitives are stored in this node.
For every complex type a new subnode is created containing the class
property of the complex type. This is pretty much a big recursion....
Please have a look at the code for more details.

Also check out the spec 0.16.2: chapter 6.7.4,, 6.7.21
> some initial ideas:
> a) Maybe we can use the Struts bean introspection to check the beans,
> create the nodetypes out of that information and registering them. Too
> bad, that creation and registering of nodetypes is not part of the
> JCR-spec :-(.

I don't believe nodes are intended to represent a java bean object.

> b) With
> bean class name         equals node type name and
> bean property name      equals child node name or property name
> it should be possible to use the JCR introspection to get the node values.
> Maybe we can provide the data by a generic
> Object getProperty(Object beanObject, String propertyName); method.

Please have a look at 6.2.5 of the spec. You can definately reflect on
a jcr node property but not all java primitives are supported by the
jcr, for instance int, byte and short are not available. You have to
use long instead.
> What do you think about all this?

I think your ideas are very interesting. Mapping java bean objects to
a JCR is a very common usecase (of the future...). Creating a
framework for serializing these objects into a JCR at runtime is the
way to go in my mind. Please let me know what you think about this.


View raw message