[
https://issues.apache.org/jira/browse/JCR-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571041#action_12571041
]
Michael Dürig commented on JCR-1405:
------------------------------------
I'm in favor of Angela's suggestion. I would generalize the meaning of null
returned by ChildInfo[] NodeInfo.getChildInfos() to 'ask me later'. That is,
whenever ChildInfo[] NodeInfo.getChildInfos() returns null, the spi
implementation cannot or for some reason deliberately does not want to return
the ChildInfos. The client would then have to collect the ChildInfos later by a
call to RepositoryService.getChildInfos.
Also I think the client should use the ChildInfos returned by
NodeInfo.getChildInfos() whenever possible. It should only call
RepositoryService.getChildInfos when absolutely necessary.
> SPI: Introduce NodeInfo.getChildInfos()
> ---------------------------------------
>
> Key: JCR-1405
> URL: https://issues.apache.org/jira/browse/JCR-1405
> Project: Jackrabbit
> Issue Type: New Feature
> Components: jackrabbit-spi
> Reporter: angela
>
> Improvement suggested by Marcel:
> 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.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
