[Cps4] cps/jcr document mapping

[Florent Guillaume]

On 7 Apr 2006, at 15:51, Eric Barroca wrote:
> On 7 avr. 06, at 15:04, Florent Guillaume wrote:
>
>> On 6 Apr 2006, at 19:23, Bogdan Stefanescu wrote:
>>> It's ok from Apogee point of view.. in fact we have no requirements
>>> about the model  implementation.
>>> Apogee should be able to adapt itself to any type of repository  
>>> model -
>>> so we only need to know exactly how the cps model will be  
>>> structured to
>>> be able to implement adapters to plug it into Apogee
>> Ok, the point is really that we want to be as "natural" as  
>> possible for the JCR, so that a plugin to a non-CPS JCR would be  
>> nearly the same.
> I don't think there is a natural way for the data model. There is  
> an efficient way and that's what we are looking for.
> Apogée won't be an "JCR" browser, so it has to implement all  
> features needed by CPS like understand the security model, flexible  
> schemas, content form, etc.
> I would like to avoid focus on the *natural*. I prefer the  
> efficient way :-)
>
>
> On flexible parts of a data schemas, how do you plan to store it ?  
> As child nodes ?

There won't be flexible schemas anymore.

Instead there will be list properties holding for instance the list  
of attached files (maybe empty).
If we have specific layout requirements, for instance a specific  
order to display:
   - attached file 1
   - attached file 2
   - paragraph of text 1
   - attached file 3
   - paragraph of text 2
Then we'll have a specific additional "layout" field deciding of this  
order. In addition to the list of files and the list of paragraphs.

Another way feasible in the JCR would be to have ordered child nodes  
(properties are never ordered) for flexible attributes, but that's  
quite different from existing CPS schemas. I haven't thought about  
that yet...

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com