On 06.05.2013, at 14:45, Carsten Ziegeler <[email protected]> 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. (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. Cheers, Alex
