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
