Hi Sandro,
Here is my comments :
2005/7/14, Sandro Böhme <[EMAIL PROTECTED]>:
> 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.
>
There are 2 reasons :
1. The first reason is to be sure to support complex cases and at
least map the object by hand. If something is missing in our mapping
tools, a specific converter can be used until the solution is
implemented into the framwork. Maybe as you suggest, the
AtomicTypeConverter can solve this issue. Can you give us a concret
usage of AtomicType Converter ? A small unit test should help me to
understand.
2. Well, I would like to use this framework for CMS server which are
not yet supported JCR. JCR is quite young and than it is possible to
use a CMS server based on a propriatary API. So, Thoses converter
classes can be a solution. This is not my top first requirements. We
can imagine to refactor later (if needed). In fact, it depends on the
JCR success :-). If JCR becomes more and more popular, my proposal is
not important.
So, forget my comment if the AtomicTypeConverter can manage complex mapping.
>
> >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.
> 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.
>
Correct, After reviewing in more details, it is almost the same.
I just want to use the common apache tools to promote them :-). It is
not very good if some ASF portal projects are using some tools and
Graffito others. I would like to use the same in order to maximize the
product integration. Please, when you want to use a specific tools,
make a proposal (and vote) on the dev mailing list.
Now, I'm reviewing the mapping file (JavaToJcrMapping.xml). Here is my
comments :
* Why it is necessary to delcare the read/write methods ? Why not to
something like that :
<subitemMapping beanProperty="description"
jcrPropertyDefinition name="graffito:description"
"requiredType="jcrString" />
If you have the bean property, it is possible to find the
get/set methods.
By this way, it is less verbose. Commons BeanUtil can help to
set/get the values.
* Maybe, we have to defined some classes as Abstract and reuse their
mapping setting into their descendants. Eg. CmsObject is the ancestor
of Folders & Documents. it is usefull to defined the mapping for
CmsObject properties and than reuse it in the mapping for Folder and
Document. This should be an optional feature but I think an
interesting one.
* We have to defined some associations tags or another solution to
solve the following issue : Eg. In the mapping for CmsObject, there is
a subitemMapping entry for the ParentFolder. ParentFolder is not a
subitem of CmsObject. In real application, Folder contains a
collection of CmsObjects. So, an association tag (with a ID/path) can
be interesting for such case. If a javabean propoperty is an object,
it can be a subitem or a reference to another object somewhere in the
repository (parent node, ...)
Regards,
Christophe
