incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <s.boe...@inovex.de>
Subject Re: Mapping of Items
Date Tue, 22 Mar 2005 15:49:23 GMT
Hello,

as this is my first contribution to an open source project, please tell 
me if I'am writing to much details in this list.

Christophe Lombart wrote:
> Sandro,
> 
> Did you check what Oliver did ? I'm working with him in order to see 
Yes I did, but according to the request of Oliver, my email was just a 
first draft of the proposal.
I looked especially at JcrNodeObjectValueConverter. It looks good, but I 
would like to be more type safe. I think this would make it easier to 
browse through the content (e.g. with the Day's Content Explorer) and 
maybe to work with the content (setProperty, getProperty).

BTW: After I checked it again today I think you are right, the Struts 
bean introspection is not neccessary, the java.bean.* tools should be fine.

> what we can do together. I hope to make a proposal to this mailing asap.
> Your ideas are interesting and we are working in the same way. If you 
> have not a lot of time, please check what Oliver did and give us your 
> point of view.
> Giving your own point of view is already a great contribution.
> 
> What about the JCR node types ? Node type management seems for myself 
> the most unclear area when we are speaking about mapping java beans to a 
> JCR repo.
Does node type management mean for you to maintain the mapping between 
the two structures (use case e)? If yes, at the moment I don't have an 
idea how to handle that, because I think it is not an easy part. This is 
why I would think about it when I have done some basic work. As a 
pragmatic solution maybe we can do the maintenance of the mapping 
without an automatism at the first step.

> It should be nice to give some flexibilty : either the object gragh is 
> serialised in a unstructurred set of nodes or is serialised by following 
> mapping rules defined in a file (something like in ORM tools : OJB, ....)
> What do you think about that ?
As I have no idea yet what the advantage of the mapping rules is, I 
would vote for unstructured nodes.

Best regards,

Sandro

> 
> Christophe
> 
> Sandro Böhme wrote:
> 
>> Hello,
>>
>> 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 think use case e) need some definition (specification like 
>> xdoclet,... or a user interface) what to do with data whose type has 
>> changed. So I would think about further until the basics work.
>> I'am sorry in advance, because I have not that much spare time, so it 
>> will need some time until I can complete some tasks. But I will do my 
>> best.
>> 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()
>> ...
>>
>> 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 :-(.
>> 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.
>>
>> c) Similar to b)
>> Maybe we can set the data by a generic
>> void setProperty(Object beanObject, String propertyName); method.
>>
>> d) We could provide two save methods like saveBean(Object beanObject) 
>> and saveBeanProperty(Object beanObject, String beanProperty).
>>
>> When I thought about mapping a bean class graph to a persisting graph 
>> I thought this problem should be already solved some years ago by 
>> object databases. So I will do some research if there are some 
>> tools/concepts which will work in our use cases.
>> What do you think about all this?
>>
>> Best regards,
>>
>> Sandro
>>
>> Oliver Kiessler wrote:
>>
>>> On Fri, 18 Mar 2005 21:39:30 +0100, Christophe Lombart
>>> <christophe.lombart@sword-technologies.com> wrote:
>>>
>>>> Sandro Böhme wrote:
>>>>
>>>>
>>>>> Hello Christophe,
>>>>>
>>>>> at the jackrabbit mailing list you said, you may want to implement a
>>>>> mapping layer between java objects and node objects. If there is
>>>>> nothing yet started in this direction I would try to implement a first
>>>>> version of it. If there is already some work done, I would like to
>>>>> participate, if you want.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Sandro
>>>>>
>>>>
>>>> Olivier Kiessler is working on that (see on
>>>> http://www.techblogs.de/roller/page/okiess). You are welcome to join
>>>> us.  It should be nice to see ASAP a proposal on that topic.
>>>
>>>
>>>
>>>
>>> Yes, I have written some code for JCR object persistence/mapping. It
>>> is not officially available yet, but if you are interested to join in
>>> or have a look at it, you are very welcome. Let me know and I'll send
>>> you the source code.
>>>
>>> regards,
>>> oliver
>>>
>>>
>>
> 
> 

Mime
View raw message