Re: mix:referenceable with OCM

[Christophe Lombart <ch...@gmail.com>]

There are also some converters (bean & collection) to manage referenceable
nodes. We should explain more in some docs but you can check the unit tests
in the first time.

For ex.

you have a class like :

Class MyContent
       AnotherContent anotherContent

anotherContent (a bean attribute) can be mapped into a REFERENCE property.
In this case, the bean cannot be updated.

If I did it correctly :-), the differente possibilities are in the unit test
ObjectContentManagerUuidTest. Check the object model and its mapping
definition to get more idea on how to map.


On 10/4/07, Felix Meschberger <fm...@gmail.com> wrote:
>
> Am Donnerstag, den 04.10.2007, 04:00 -0700 schrieb Kaizer:
> > I'm a little confused about how the mix:referenceable works in OCM. The
> uuid
> > will be stored as an attribute in my class but how is the reference
> stored?
> > I'd appreciate it if someone can explain with an example.
>
> Not sure, whether I understand your question. The UUID is stored in the
> jcr:uuid property in the node and may be mapped to any field in your
> class. But you should consider that field read-only, as the repository
> manages the jcr:uuid property and won't let you change it (actually, OCM
> will not even try to write protected properties such as jcr:uuid).
>
> If another node refers the mix:referenceable node, it stores that UUID
> in any property of type REFERENCE, which you may easily store in a
> String field.
>
> Regards
> Felix
>
>

Re: mix:referenceable with OCM

[Christophe Lombart <ch...@gmail.com>]

On 10/5/07, Kaizer <Ka...@mastek.com> wrote:
>
>
> Thanks a lot! I had a look at the test cases and that helped! But i had a
> few
> general queries..
> 1. What are the advantages of using referencing here? One can still
> persist
> "anotherContent" by specifying its attributes in the mapping.xml, so when
> should i consider using referencing?




If you specify "anotherContent" as a bean-descriptor in the main object (in
our case "MyContent"),  by default, that means it is a subnode of
"MyContent". there are some situation where you want to point to another
node (which is not a subnode).

Maybe a good exemple is : one article has a list of related articles. here
is the repo structure(with very bad name).

/articles/article1
     UUID : 123455
     text: "....."
     ....
/articles/article2
     UUID  : 6987787
     text: "....."
/articles/article3
     UUID : 9966565
     text: "....."
     RelatedArticles : 123455, 6987787
/articles/article4
     UUID : 66655656
     text: "....."
/articles/article5
     UUID : 12890
     text: "....."
     RelatedArticles : 66655656

In this case, when I update my article, this is not necessary to update the
related article contents. I can only modify the list of the related
articles. In such case, you can use multi value property based on the
REFERENCE type (RelatedArticles). The OCM converter
"RefenceCollectionConverterImpl" is doing this for you.

But there are some alternatives to referencable nodes  :-) (see
http://wiki.apache.org/jackrabbit/DavidsModel#head-ed794ec9f4f716b3e53548be6dd91b23e5dd3f3a
).
We should provide some converters to support this kind of proposal. I Think
is should be possible to build a variant of ReferenceCollectionConverterImpl
(and ReferenceBeanConverterImpl)  that provide the flexibility defined in
the David's Rule 5.




2. As per the documentation of ReferenceBeanConverterImpl, modifications on
> the referenced bean attributes are ignored. Does this mean that after
> persisting, if "anotherContent" is modified, the reference in "myContent"
> will not reflect the changes?


No with the following code, that's ok :

AnotherContent anotherContent = new AnotherContent();
anotherContent.setMyProp("pop1");
anotherContent.setPath("/anotherContent);
ocm.insert(anotherContent);
ocm.save();
....
MyContent myContent = new MyContent();
myContent.setPath("/mycontent");
myContent.setAnotherContent(anotherContent)
...
ocm.insert(myContent);
ocm.save();  // another content will not be a subnode of mycontent. Only its
uuid is stored as REFERENCE prop inside myContent


MyContent myContent = ocm.getObject("/myContent);
anotherContent  = myContent.getAnotherContent();
String prop = anotherContent.getMyProp(); // if proxy = true, the retrieve
of anotherContent is made at that time.

myContent.getAnotherContent()..setMyProp("pop1"); // This update will be
ignored by the ocm


AnotherContent   = ocm.getObject("/anotherContent);
anotherContent.setMyProp("pop2");
ocm.update(anotherContent);
ocm.save();






Let me know if it is not clear (sorry it is friday :-) )


br,
Christophe

Re: mix:referenceable with OCM

[Kaizer <Ka...@mastek.com>]

Thanks a lot! I had a look at the test cases and that helped! But i had a few
general queries..
1. What are the advantages of using referencing here? One can still persist
"anotherContent" by specifying its attributes in the mapping.xml, so when
should i consider using referencing?
2. As per the documentation of ReferenceBeanConverterImpl, modifications on
the referenced bean attributes are ignored. Does this mean that after
persisting, if "anotherContent" is modified, the reference in "myContent"
will not reflect the changes?

Thanks.

Regards
Kaizer



Christophe Lombart wrote:
> 
> There are also some converters (bean & collection) to manage referenceable
> nodes. We should explain more in some docs but you can check the unit
> tests
> in the first time.
> 
> For ex.
> 
> you have a class like :
> 
> Class MyContent
>        AnotherContent anotherContent
> 
> anotherContent (a bean attribute) can be mapped into a REFERENCE property.
> In this case, the bean cannot be updated.
> 
> If I did it correctly :-), the differente possibilities are in the unit
> test
> ObjectContentManagerUuidTest. Check the object model and its mapping
> definition to get more idea on how to map.
> 
> 
> On 10/4/07, Felix Meschberger <fm...@gmail.com> wrote:
>>
>> Am Donnerstag, den 04.10.2007, 04:00 -0700 schrieb Kaizer:
>> > I'm a little confused about how the mix:referenceable works in OCM. The
>> uuid
>> > will be stored as an attribute in my class but how is the reference
>> stored?
>> > I'd appreciate it if someone can explain with an example.
>>
>> Not sure, whether I understand your question. The UUID is stored in the
>> jcr:uuid property in the node and may be mapped to any field in your
>> class. But you should consider that field read-only, as the repository
>> manages the jcr:uuid property and won't let you change it (actually, OCM
>> will not even try to write protected properties such as jcr:uuid).
>>
>> If another node refers the mix:referenceable node, it stores that UUID
>> in any property of type REFERENCE, which you may easily store in a
>> String field.
>>
>> Regards
>> Felix
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/mix%3Areferenceable-with--OCM-tf4568070.html#a13053367
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.