You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Amit.. Gupta." <am...@adobe.com> on 2013/05/06 14:37:55 UTC
RE: Please vote for SLING-2853 (content Structure)
I am in favour of keeping both jcr:content and sling:members, it might look additional today. But this will ensure that we have enough flexibility to evolve in future.
If this looks fine to everyone, I can work on a patch..
Thanks,
-Amit
-----Original Message-----
From: Felix Meschberger [mailto:fmeschbe@adobe.com]
Sent: 06 May 2013 13:13
To: dev@sling.apache.org
Subject: Re: Please vote for SLING-2853
Hi
I have just committed the latest patch. Thanks for that so far.
I am sure the discussion and fine-tuning will continue. So I invite to continue such discussions and create follow-up issues for implementation/fixes/etc.
As for the last comment by AlexK: Yes, the jcr:content/sling:members child node may sound like an additional redirection. On the other hand it will help keeing the tree structure structurized -- Once we have some data stored out there it will probably become harder and harder to change the structure later. So much like API I like to get data structures right as early as possible.
Regards
Felix
Am 06.05.2013 um 09:11 schrieb Felix Meschberger:
> Hi
>
> Am 06.05.2013 um 08:54 schrieb Bertrand Delacretaz:
>
>> On Sun, May 5, 2013 at 11:40 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>> ...One thing we imho should discuss is whether this should be using
>>> the api package, like o.a.s.api.resource.collection; We could leave
>>> it in the separate bundle as is right now, and once we consider it
>>> stable, move the package to the official API package....
>>
>> That would work but there's some potential for confusion if we do
>> that, I prefer a separate o.a.s.collections package as now.
>
> Yes, the current proposal is o.a.s.resource.collections which sounds
> good IMHO
>
> Regards
> Felix
Re: Please vote for SLING-2853 (content Structure)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 06.05.2013 um 15:37 schrieb Alexander Klimetschek:
> On 06.05.2013, at 14:45, Carsten Ziegeler <cz...@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
Re: Please vote for SLING-2853 (content Structure)
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 06.05.2013, at 14:45, Carsten Ziegeler <cz...@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.
(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
RE: Please vote for SLING-2853 (content Structure)
Posted by "Amit.. Gupta." <am...@adobe.com>.
Fixed the name of the node as sling:members in https://issues.apache.org/jira/browse/SLING-2857
Also, fixed the name of the property to sling:resources to make it consistent with sling:resource. Also, fixed another minor issue.
Patch is attached in the bug.
Thanks,
Amit
-----Original Message-----
From: Carsten Ziegeler [mailto:cziegeler@apache.org]
Sent: 06 May 2013 23:49
To: dev@sling.apache.org
Subject: Re: Please vote for SLING-2853 (content Structure)
The only potential reason I see for jcr:content is if we allow a hierarchy of collections, so /a/b points to collection B and /a/b/c points to collection C.
Carsten
2013/5/6 Carsten Ziegeler <cz...@apache.org>
> Ok, found it in the bug; I think "sling:members" is fine and I don't
> see any need for jcr:content. It doesn't provide any additional value,
> so let's just go with sling:members
>
> Carsten
>
>
> 2013/5/6 Carsten Ziegeler <cz...@apache.org>
>
>> Sorry to ask, but what is jcr:content for?
>>
>> Regards
>> Carsten
>>
>>
>> 2013/5/6 Amit.. Gupta. <am...@adobe.com>
>>
>> I am in favour of keeping both jcr:content and sling:members, it
>> might
>>> look additional today. But this will ensure that we have enough
>>> flexibility to evolve in future.
>>>
>>> If this looks fine to everyone, I can work on a patch..
>>>
>>> Thanks,
>>> -Amit
>>>
>>> -----Original Message-----
>>> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
>>> Sent: 06 May 2013 13:13
>>> To: dev@sling.apache.org
>>> Subject: Re: Please vote for SLING-2853
>>>
>>> Hi
>>>
>>> I have just committed the latest patch. Thanks for that so far.
>>>
>>> I am sure the discussion and fine-tuning will continue. So I invite
>>> to continue such discussions and create follow-up issues for
>>> implementation/fixes/etc.
>>>
>>> As for the last comment by AlexK: Yes, the jcr:content/sling:members
>>> child node may sound like an additional redirection. On the other
>>> hand it will help keeing the tree structure structurized -- Once we
>>> have some data stored out there it will probably become harder and
>>> harder to change the structure later. So much like API I like to get
>>> data structures right as early as possible.
>>>
>>> Regards
>>> Felix
>>>
>>> Am 06.05.2013 um 09:11 schrieb Felix Meschberger:
>>>
>>> > Hi
>>> >
>>> > Am 06.05.2013 um 08:54 schrieb Bertrand Delacretaz:
>>> >
>>> >> On Sun, May 5, 2013 at 11:40 AM, Carsten Ziegeler <
>>> cziegeler@apache.org> wrote:
>>> >>> ...One thing we imho should discuss is whether this should be
>>> >>> using the api package, like o.a.s.api.resource.collection; We
>>> >>> could leave it in the separate bundle as is right now, and once
>>> >>> we consider it stable, move the package to the official API package....
>>> >>
>>> >> That would work but there's some potential for confusion if we do
>>> >> that, I prefer a separate o.a.s.collections package as now.
>>> >
>>> > Yes, the current proposal is o.a.s.resource.collections which
>>> > sounds good IMHO
>>> >
>>> > Regards
>>> > Felix
>>>
>>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
--
Carsten Ziegeler
cziegeler@apache.org
RE: Please vote for SLING-2853 (content Structure)
Posted by "Amit.. Gupta." <am...@adobe.com>.
That does not seem to be a use case so far for collections..
-Amit
-----Original Message-----
From: Carsten Ziegeler [mailto:cziegeler@apache.org]
Sent: 06 May 2013 23:49
To: dev@sling.apache.org
Subject: Re: Please vote for SLING-2853 (content Structure)
The only potential reason I see for jcr:content is if we allow a hierarchy of collections, so /a/b points to collection B and /a/b/c points to collection C.
Carsten
2013/5/6 Carsten Ziegeler <cz...@apache.org>
> Ok, found it in the bug; I think "sling:members" is fine and I don't
> see any need for jcr:content. It doesn't provide any additional value,
> so let's just go with sling:members
>
> Carsten
>
>
> 2013/5/6 Carsten Ziegeler <cz...@apache.org>
>
>> Sorry to ask, but what is jcr:content for?
>>
>> Regards
>> Carsten
>>
>>
>> 2013/5/6 Amit.. Gupta. <am...@adobe.com>
>>
>> I am in favour of keeping both jcr:content and sling:members, it
>> might
>>> look additional today. But this will ensure that we have enough
>>> flexibility to evolve in future.
>>>
>>> If this looks fine to everyone, I can work on a patch..
>>>
>>> Thanks,
>>> -Amit
>>>
>>> -----Original Message-----
>>> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
>>> Sent: 06 May 2013 13:13
>>> To: dev@sling.apache.org
>>> Subject: Re: Please vote for SLING-2853
>>>
>>> Hi
>>>
>>> I have just committed the latest patch. Thanks for that so far.
>>>
>>> I am sure the discussion and fine-tuning will continue. So I invite
>>> to continue such discussions and create follow-up issues for
>>> implementation/fixes/etc.
>>>
>>> As for the last comment by AlexK: Yes, the jcr:content/sling:members
>>> child node may sound like an additional redirection. On the other
>>> hand it will help keeing the tree structure structurized -- Once we
>>> have some data stored out there it will probably become harder and
>>> harder to change the structure later. So much like API I like to get
>>> data structures right as early as possible.
>>>
>>> Regards
>>> Felix
>>>
>>> Am 06.05.2013 um 09:11 schrieb Felix Meschberger:
>>>
>>> > Hi
>>> >
>>> > Am 06.05.2013 um 08:54 schrieb Bertrand Delacretaz:
>>> >
>>> >> On Sun, May 5, 2013 at 11:40 AM, Carsten Ziegeler <
>>> cziegeler@apache.org> wrote:
>>> >>> ...One thing we imho should discuss is whether this should be
>>> >>> using the api package, like o.a.s.api.resource.collection; We
>>> >>> could leave it in the separate bundle as is right now, and once
>>> >>> we consider it stable, move the package to the official API package....
>>> >>
>>> >> That would work but there's some potential for confusion if we do
>>> >> that, I prefer a separate o.a.s.collections package as now.
>>> >
>>> > Yes, the current proposal is o.a.s.resource.collections which
>>> > sounds good IMHO
>>> >
>>> > Regards
>>> > Felix
>>>
>>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Please vote for SLING-2853 (content Structure)
Posted by Carsten Ziegeler <cz...@apache.org>.
The only potential reason I see for jcr:content is if we allow a hierarchy
of collections, so /a/b points to collection B and /a/b/c points to
collection C.
Carsten
2013/5/6 Carsten Ziegeler <cz...@apache.org>
> Ok, found it in the bug; I think "sling:members" is fine and I don't see
> any need for jcr:content. It doesn't provide any additional value, so let's
> just go with sling:members
>
> Carsten
>
>
> 2013/5/6 Carsten Ziegeler <cz...@apache.org>
>
>> Sorry to ask, but what is jcr:content for?
>>
>> Regards
>> Carsten
>>
>>
>> 2013/5/6 Amit.. Gupta. <am...@adobe.com>
>>
>> I am in favour of keeping both jcr:content and sling:members, it might
>>> look additional today. But this will ensure that we have enough flexibility
>>> to evolve in future.
>>>
>>> If this looks fine to everyone, I can work on a patch..
>>>
>>> Thanks,
>>> -Amit
>>>
>>> -----Original Message-----
>>> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
>>> Sent: 06 May 2013 13:13
>>> To: dev@sling.apache.org
>>> Subject: Re: Please vote for SLING-2853
>>>
>>> Hi
>>>
>>> I have just committed the latest patch. Thanks for that so far.
>>>
>>> I am sure the discussion and fine-tuning will continue. So I invite to
>>> continue such discussions and create follow-up issues for
>>> implementation/fixes/etc.
>>>
>>> As for the last comment by AlexK: Yes, the jcr:content/sling:members
>>> child node may sound like an additional redirection. On the other hand it
>>> will help keeing the tree structure structurized -- Once we have some data
>>> stored out there it will probably become harder and harder to change the
>>> structure later. So much like API I like to get data structures right as
>>> early as possible.
>>>
>>> Regards
>>> Felix
>>>
>>> Am 06.05.2013 um 09:11 schrieb Felix Meschberger:
>>>
>>> > Hi
>>> >
>>> > Am 06.05.2013 um 08:54 schrieb Bertrand Delacretaz:
>>> >
>>> >> On Sun, May 5, 2013 at 11:40 AM, Carsten Ziegeler <
>>> cziegeler@apache.org> wrote:
>>> >>> ...One thing we imho should discuss is whether this should be using
>>> >>> the api package, like o.a.s.api.resource.collection; We could leave
>>> >>> it in the separate bundle as is right now, and once we consider it
>>> >>> stable, move the package to the official API package....
>>> >>
>>> >> That would work but there's some potential for confusion if we do
>>> >> that, I prefer a separate o.a.s.collections package as now.
>>> >
>>> > Yes, the current proposal is o.a.s.resource.collections which sounds
>>> > good IMHO
>>> >
>>> > Regards
>>> > Felix
>>>
>>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Please vote for SLING-2853 (content Structure)
Posted by Carsten Ziegeler <cz...@apache.org>.
Ok, found it in the bug; I think "sling:members" is fine and I don't see
any need for jcr:content. It doesn't provide any additional value, so let's
just go with sling:members
Carsten
2013/5/6 Carsten Ziegeler <cz...@apache.org>
> Sorry to ask, but what is jcr:content for?
>
> Regards
> Carsten
>
>
> 2013/5/6 Amit.. Gupta. <am...@adobe.com>
>
> I am in favour of keeping both jcr:content and sling:members, it might
>> look additional today. But this will ensure that we have enough flexibility
>> to evolve in future.
>>
>> If this looks fine to everyone, I can work on a patch..
>>
>> Thanks,
>> -Amit
>>
>> -----Original Message-----
>> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
>> Sent: 06 May 2013 13:13
>> To: dev@sling.apache.org
>> Subject: Re: Please vote for SLING-2853
>>
>> Hi
>>
>> I have just committed the latest patch. Thanks for that so far.
>>
>> I am sure the discussion and fine-tuning will continue. So I invite to
>> continue such discussions and create follow-up issues for
>> implementation/fixes/etc.
>>
>> As for the last comment by AlexK: Yes, the jcr:content/sling:members
>> child node may sound like an additional redirection. On the other hand it
>> will help keeing the tree structure structurized -- Once we have some data
>> stored out there it will probably become harder and harder to change the
>> structure later. So much like API I like to get data structures right as
>> early as possible.
>>
>> Regards
>> Felix
>>
>> Am 06.05.2013 um 09:11 schrieb Felix Meschberger:
>>
>> > Hi
>> >
>> > Am 06.05.2013 um 08:54 schrieb Bertrand Delacretaz:
>> >
>> >> On Sun, May 5, 2013 at 11:40 AM, Carsten Ziegeler <
>> cziegeler@apache.org> wrote:
>> >>> ...One thing we imho should discuss is whether this should be using
>> >>> the api package, like o.a.s.api.resource.collection; We could leave
>> >>> it in the separate bundle as is right now, and once we consider it
>> >>> stable, move the package to the official API package....
>> >>
>> >> That would work but there's some potential for confusion if we do
>> >> that, I prefer a separate o.a.s.collections package as now.
>> >
>> > Yes, the current proposal is o.a.s.resource.collections which sounds
>> > good IMHO
>> >
>> > Regards
>> > Felix
>>
>>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Please vote for SLING-2853 (content Structure)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sorry to ask, but what is jcr:content for?
Regards
Carsten
2013/5/6 Amit.. Gupta. <am...@adobe.com>
> I am in favour of keeping both jcr:content and sling:members, it might
> look additional today. But this will ensure that we have enough flexibility
> to evolve in future.
>
> If this looks fine to everyone, I can work on a patch..
>
> Thanks,
> -Amit
>
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
> Sent: 06 May 2013 13:13
> To: dev@sling.apache.org
> Subject: Re: Please vote for SLING-2853
>
> Hi
>
> I have just committed the latest patch. Thanks for that so far.
>
> I am sure the discussion and fine-tuning will continue. So I invite to
> continue such discussions and create follow-up issues for
> implementation/fixes/etc.
>
> As for the last comment by AlexK: Yes, the jcr:content/sling:members child
> node may sound like an additional redirection. On the other hand it will
> help keeing the tree structure structurized -- Once we have some data
> stored out there it will probably become harder and harder to change the
> structure later. So much like API I like to get data structures right as
> early as possible.
>
> Regards
> Felix
>
> Am 06.05.2013 um 09:11 schrieb Felix Meschberger:
>
> > Hi
> >
> > Am 06.05.2013 um 08:54 schrieb Bertrand Delacretaz:
> >
> >> On Sun, May 5, 2013 at 11:40 AM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> >>> ...One thing we imho should discuss is whether this should be using
> >>> the api package, like o.a.s.api.resource.collection; We could leave
> >>> it in the separate bundle as is right now, and once we consider it
> >>> stable, move the package to the official API package....
> >>
> >> That would work but there's some potential for confusion if we do
> >> that, I prefer a separate o.a.s.collections package as now.
> >
> > Yes, the current proposal is o.a.s.resource.collections which sounds
> > good IMHO
> >
> > Regards
> > Felix
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Please vote for SLING-2853 (content Structure)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, May 6, 2013 at 2:37 PM, Amit.. Gupta. <am...@adobe.com> wrote:
> I am in favour of keeping both jcr:content and sling:members...
> If this looks fine to everyone, I can work on a patch..
Works for me as long as it's covered by tests...otherwise the risk of
changing behavior without noticing is real.
-Bertrand