Content structure and resulting SPI implementation

[Pierre Leman <pi...@gmail.com>]

Hi,


According to the content driven design approach, I designed the content
before doing the application's implementation.
My question concerned the better way to reflect the content structure in an
SPI implementation.
I saw that the RepositoryInterface declared some interesting method like
getNodeInfo, getPropertyInfo and getChildInfo.
Considering that the choice between getNodeInfo, getPropertyInfo and
getChildInfo was function of the type of the item on which the path pointed
(but maybe I'm wrong ?), I was thinking of trying to parse the ItemId path
in order to decide what have to be done for each item type (node, property
...) in function of its path (giving it a semantic from my data model's
point of view).
So in this hypothesis we get the following choice hierarchy :
First : function of the type of the ItemId.
Second : function of the path of the ItemId.

>From the point of view of what the *Info method have to handle, I was
thinking first of the hierarchy (giving each item a parent Id for example)
and then to the data (reading it directly from my data model, a database
thanks to the intermediary of a JDBC API). Did I forget something ?

Thank you all for your answers !
Pierre

Re: Content structure and resulting SPI implementation

[Pierre Leman <pi...@gmail.com>]

Hi angela


Sorry for not being enough clear on my last question.
This question concerns the call conditions of the get*Info methods and what
they're expected to return.

I think I found the solution :
Each *Info method of the RepositoryService interface corresponds to a JCR
equivalent method (without the Info suffix).
Each time a user call one of these functions through the JCR API (exposed by
jcr2spi), the jcr2spi calls the corresponding get*Info method to build the
requested item (node, property, ...).
Consequently, it have to provide all the informations needed to build a
complete item "from scratch" and to insert it into the JCR tree.
It's what I call the "hierarchy informations" (id of the parent, ...) and
the "data informations" (value of property, name of node, ...).
I get the "hierarchy informations" directly from my SPI implementation and
the "data informations" from my database through the JDBC API.
Do you think I'm right now ?

I read the JIRA issues you furnished, finding it very interesting. The
Apache Development List is also very helpful.

Thanks !
Best regards,
Pierre

Re: Content structure and resulting SPI implementation

[Angela Schreiber <an...@day.com>]

hi pierre

> My question concerned the better way to reflect the content structure in an
> SPI implementation.
> I saw that the RepositoryInterface declared some interesting method like
> getNodeInfo, getPropertyInfo and getChildInfo.

and getItemInfos.

- getItemInfos: retrieve a NodeInfo and optionally additional NodeInfos
                 or PropertyInfos (from below that node). batched read.
- getNodeInfo : basically replaced by getItemInfos
- getPropertyInfo: retrieve a single property info.
- getChildInfo: retrieve name/index/id of all child-nodes of a node.
   see also the following jira issues: JCR-1405, JCR-1239

> Considering that the choice between getNodeInfo, getPropertyInfo and
> getChildInfo was function of the type of the item on which the path pointed
> (but maybe I'm wrong ?), 

see above

> I was thinking of trying to parse the ItemId path
> in order to decide what have to be done for each item type (node, property
> ...) in function of its path (giving it a semantic from my data model's
> point of view).

not quite. the type of item (Property or Node) is defined by
the ItemId (see ItemId#denotesNode). there is never an unspecified
item type. or do you mean something different?

> So in this hypothesis we get the following choice hierarchy :
> First : function of the type of the ItemId.
> Second : function of the path of the ItemId.
> 
> From the point of view of what the *Info method have to handle, I was
> thinking first of the hierarchy (giving each item a parent Id for example)
> and then to the data (reading it directly from my data model, a database
> thanks to the intermediary of a JDBC API). Did I forget something ?

sorry, i didn't get that.

angela