Marcel Reutegger wrote:
Hmmm, does that mean a batch read should also be allowed to return
ChildInfo, with the restriction that it must be complete, when sent?
That would be less expensive than returning ItemInfos for the
children. But would it be useful?
Maybe the more interesting question is, how useful is it to have the
distinction between NodeInfo and ChildInfo?
ChildInfo is basically a stripped down NodeInfo. With little effort it
would even be possible to have NodeInfo extends ChildInfo. Not sure how
useful that is, but since we don't have that inheritance in code and at
the same time nearly a 100% overlap it makes me suspicious.
Yep.
Here's another idea:
introduce a method ChildInfo[] NodeInfo.getChildInfos(). The method
either returns:
- all child infos, which also gives the correct number of child nodes.
this may also mean that an empty array is returned to indicate there are
no child nodes.
- null, to indicate that there are *lots* of child nodes and the method
RepositoryService.getChildInfos() with the iterator should be used.
Having the method on NodeInfo would help keeping state; but my
impression was that this design pattern was something we don't do. For
instance, why wouldn't we also use it for retrieving properties (which
has similar problems)?
I am also not sure why we just wouldn't want getChildInfos return
something that can both provide members, the count, and be evaluated
lazily when needed.
And how should the SPI implementation know that somebody *wants* to
retrieve all children?
I'm not sure I understand your question, because there is
RepositoryService.getChildInfos(). Do you mean something else?
I was thinking in terms of PROPFIND Depth 0/1, where 1 includes 0.
That is, it's possible to return information about the node and all
it's children, saving yet another round trip. Which may not be
sufficient justification.
But returning ChildInfos will not be sufficient here, because there is
no Batch aspect built in; thus, JCR2SPI still needs to fetch the
ItemInfos for each child node in a separate call.
example content:
/a
/b
/c
Considering the above mentioned method an SPI implementation could return:
NodeInfo(a, [ChildInfo(b), ChildInfo(c)]), NodeInfo(b, []), NodeInfo(c, [])
plus whatever properties are considered useful.
would that work?
Yes, in particular if we make NodeInfo extend ChildInfo, so no
duplication is needed here.
BR, Julian
