incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <sandro.boe...@gmx.de>
Subject Re: [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Date Thu, 14 Jul 2005 19:10:05 GMT
Christophe Lombart wrote:

>Hi Sandro,
>
>Here is my comments : 
>
>
>2005/7/14, Sandro Böhme <sandro.boehme@gmx.de>:
>
>  
>
>>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.
>
>  
>
I guess you describe pretty exactly what I've initially written in this 
JIRA issue :-) :
"In my opinion, if I don't ignore something, the mapping project can 
also be useful

for CMS's that don't want to change very much of their domain model and instead
want to use our mapping to adopt their classes to nodetypes."
So it's good to see you have the same opinion ;-).

To be sure I know what you mean, can you please send me a class 
structure as an example? I will try
to create the according test case.

>>>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.
>
>  
>
I guess you speak about the JAXB RI? I know what you mean. I really 
don't want to
dictate any tool. Basically the reason why I started this thread was to 
get your opinion
about my initial codebase instead to simply commit the things. But I 
will make a proposal
for the use of third party libraries the next time also for delivering 
them in JIRA. It's not
a problem.

>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.
>  
>
The reason was, to be able to map POJO's but I like your idea.
Also in this matter, I would like to add your idea as an additional
feature. The user would not need to specify the read/write methods
and he can specify the bean property instead. Is it ok to leave
the read/write as an alternative for POJO's in you opinion?

>* 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.
>  
>
I planned to realized this with mapping the supertypes of the JCR to
the supertypes of Java as both have an inheritence mechanism. As soon as 
I found a way to
register custom supertypes in Jackrabbit it should really not be a 
problem to have a
streamlined implementation of that feature.

>* 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, ...)
>
>  
>
Do you mean a link from a "mapping managed node" to an arbitrary node in 
the repository
not managed by the mapping framework? What would be the Java 
representation of such a
node?
If you mean persisting object trees, this should already be possible. 
Please have a look
at PersistenceManagerTest.testInsertAndCheckDocument(). This inserts a 
Document object
having a Content object.  A search for the Content node returns a path
"/graffito:Document1/graffito:content".

>Regards,
>Christophe
>  
>

Best regards,

Sandro

Mime
View raw message