On 06.05.2013, at 14:40, Bertrand Delacretaz <[email protected]> wrote:
> On Mon, May 6, 2013 at 2:29 PM, Carsten Ziegeler <[email protected]> wrote: >> ...I looked at the recent version of the ResourceCollectionManager. I'm fine >> with the API, but why not make this a simple service which one can lookup >> from the service registry?... > > +1, I noticed that when reviewing that code this morning but didn't > act on that notice ;-) This touches on the topic on how things like this on top of the resource API should work in general. AFAIK, this is a first here. Citing my review from [0]: The ResourceCollectionManager is really only needed to create a new collection (get and delete can be done via adaptTo and Resource directly). That somewhat bloats API client code a bit, "only" getting the manager for creation. But I don't know what is better - a static create method on ResourceCollection would break into the API and don't see other ways. Do we have any precedence in Sling with code like this, creating content structures on top of the resource API? Some loose thoughts: - Having it as a service sounds a bit overkill... - IMHO it should not be an invite to start doing background things, cleanup or eventing as mentioned a few times. It should work even if the content is created through other means. - If client code mixes different resource resolvers it has other problems :-) The api docs could state that clearly. [0] https://issues.apache.org/jira/browse/SLING-2853?focusedCommentId=13649346&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13649346 Cheers, Alex
