Hi Am 06.05.2013 um 15:37 schrieb Alexander Klimetschek:
> On 06.05.2013, at 14:45, Carsten Ziegeler <cziege...@apache.org> wrote: > >> Sorry to ask, but what is jcr:content for? > > Same here - sling:members as intermediary node solves the issue of reducing > conflicts already. Introducing yet another intermediary doesn't bring > anything new to the table. Any extension (e.g. a "thumbnail" node) can be > placed as sibling to the sling:members node. As listed in the issue: The collection node is probably nt:hiearchyNode. So the contents should be in a jcr:content child node (best practices style à-la nt:file). The sling:members node is a child node to have all members of the collection within a single child node without interfering with meta data of the collection it self such as a jcr:title, jcr:description, or some thumbnail image resource node. > > (Note that I initially argued for jcr:content but that was just as a > different name for the sling:members node). > > Other things: > > - Please rename "sling:references" to "sling:resources" to be in line with > the "sling:resource" property. I don't care which (reference or resource), > but the property names should be consistent. > > - add(res) could be implemented as just "add(res, null)" to avoid code > duplication. > > - there is no way in the API to get to the properties on the collection level > (added via "createCollection(Resource, String, Map<String, Object>)"); you > can get it if you have the resource that represents the collection node, but > I guess the API could have it as well. Or we keep it simple and the > collection has a getResource() or extends from and wraps the Resource right > away. Yes, maybe ResourceCollection.adaptTo(ValueMap.class) ? In any case separating the resource colleciton properties (in the jcr:content node) and the members (in the jcr:content/jcr:members child) makes separation simple and clean. At least IMHO. Regards Felix > > Cheers, > Alex
