[
https://issues.apache.org/jira/browse/SLING-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13648941#comment-13648941
]
Amit Gupta commented on SLING-2853:
-----------------------------------
> Your bundle provides API in the o.a.s.api namespace. I think this namespace
> should be reserved for the Sling API bundle. So either the new API is in the
> o.a.s.resource.collection (or similar) namespace or is moved to the Sling API
> bundle.
refactored
> ResourceCollectionUtil.createValidChildName actually does
> "createUniqueChildName" and should maybe provided in the existing
> ResourceUtil class (IIRC the Sling POST Servlet has a similar method)
Refactored the name, one can move it to ResourceUtil, while applying the patch.
> ResourceCollectionManager.getByPath should probably be renamed to
> ResourceCollectionManager.getCollection to align with the createCollection
> method.
refactored
> ResourceCollectionManager declares its methods to be transient referring to
> ResourceResolver.commit. At least I think the JavaDoc of this interface must
> define how one can get an instance of the ResourceResolverManager and how it
> relates to the ResourceResolver. Maybe the ResourceResolver used by the
> ResourceResolverManager should be exposed through a getResourceResolver
> method.
Updated java doc, added a getRsourceResolver() method
> The ResourceCollection interface exposes the resources exposed but does not
> expose the collection entries are said to have additional properties in the
> future. What is the way forward here ?
Added aditional api getEntries() and updated javadoc to make it more clear.
Collection.add now takes a map of additional properties which can be null
> ResourceCollections don't seem to be orderable ? Would ordering be simulated
> by an order property on the resourceCollection root resource ?
added implementation for ordering, a new api orderBefore is added to maintain
the order
> Automated tests wouldn't hurt, of course.
Added Junit test cases.
> Can't you use the adapter pattern Instead of
> ResourceCollectionManager.getByPath(...) ? Adapt a Resource to a
> ResourceCollectionManager.
Intentionally kept that way so that if there is any additional code needs to be
executed on delete of collection, then can be plugged in/added. To create
instance of ResourceCollectionManager, one can adapt from ResourceResolver.
Please review the latest patch.
Regards,
Amit
> Add ResourceCollection to Sling
> -------------------------------
>
> Key: SLING-2853
> URL: https://issues.apache.org/jira/browse/SLING-2853
> Project: Sling
> Issue Type: New Feature
> Components: API
> Affects Versions: API 2.0.2
> Reporter: Amit Gupta
> Priority: Minor
> Attachments: collection.zip, resourcecollection.zip
>
>
> Creating a collection of resources has been a use case for a while and there
> has been no inherent support in SLING for the same.
> This proposal is to add a ResourceCollection interface and implementation
> that allows creation of collection of resources.
> Collection is a simple list of members, where each member contains path of
> resource it refers to. In future, we might need to store additional
> information with the member, hence following structure is proposed
> N: resourceCollection (nt:unstructured)
> + P: sling:resourceType
> + N : members (nt:unstructured)
> + N: member_res1 > nt:unstructured
> + P: path > string, reference to actual resource
> + N: member_res2 > nt:unstructured
> + P: path > string, reference to actual resource
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
