[
https://issues.apache.org/jira/browse/SLING-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13649352#comment-13649352
]
Carsten Ziegeler commented on SLING-2853:
-----------------------------------------
I agree that allowing for custom node type nodes is fine - this is already
possible today, as the create method takes a properties object, if the
jcr:primaryType property is set, this will be used as the node type.
Namespacing of properties: +1, I would go with sling:path or sling:resourcePath
- as this is what it's about, a path in the resource tree, sling:resource would
be fine as well
As we want to allow additional properties for a member, I wouldn't go with a
multi-value property, especially not with allowing both, a multi-value property
defining the collection and child nodes. This adds unnecessary complexity. And
I still would go with a members node, or sling:members, or sling:collection.
API
I think we should not rely on just the adapter pattern for getting a
collection, so as we need a manager for creation, it should also allow getting
a collection and deleting a collection. This makes it symmetric. I could
imagine that the manager does some additional work if a collection is deleted,
like sending collection events. We can clearly define in the API that
collections should be deleted through the manager.
Now, I think it will be very difficult to discuss all these different things at
once in this issue. What about applying the current patch and then discussing
the things one after the other? I totally agree that they are all important to
be discussed but I think that once we have something committed, it gets a
little bit easier to discuss.
> 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
