You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2016/03/18 08:08:55 UTC
[RT] Improve resource type handling
Hi,
in the past years we added a lot of things here and there which over
time resulted in cruft and sometimes hard to understand / debug
problems. In order to have an even better framework which is easier to
manage but also scales better for the things to come, we should get rid
of this additional weigth.
One area which I think needs attention is the resource type handling.
We started years back with the two methods on a resource, getting a
resource type and optionally getting a resource super type.
A little bit later this was extended with what we call today the
resource type hierarchy: for a resource type a/b, a resource can be
created in /libs/a/b with a resource super type property. This can be
overlayed in /apps. (I'm assuming the default search paths here to keep
it simple).
While this sounds nice and and simple, it has several drawbacks (in no
particular order):
- it's hard to find out all the super types of a resource type
- the resource resolver which reads the type hierarchy needs read access
to the complete tree of /libs and /apps - just to find a few properties
here and there.
- two resources with the same resource type, might have different
resource super types or even a complete different hierarchy.
- there is no guarantee that the resource super type is static, which
means two calls to find the super type for a resource type could result
in different results, e.g. if the resource itself decides to return a
different value, or if a resource decorator is used which does so.
- for traversing the hierarchy we currently create an additional admin
resource resolver per resource resolver - which is a huge overhead.
Especially the last three points make improving the script resolution
hard - if not impossible. Today the cache is using the resource type and
resource super type of the resource as a key. However, given the above
information it is easy to create a scenario where the cache returns a
wrong script.
Taking all these things into account, I think we should somehow start
fresh with handling the resource type hierarchy and come to a better
solution. In this first step, I think we should not care about
compatibility. Once we have a great solution, we'll find a way on how to
achieve this.
My rough initial proposal would be:
a) forget about Resource#getResourceSuperType. This method is ignored
from now on (and deprecated)
b) the resource hierarchy is not spread across /libs, /apps anymore
c) we create a dedicated resource tree at /foo (I'm using /foo as a
placeholder as I don't want to start an endless discussion now on what
this path actually really is). We then have /foo/apps and /foo/libs.
Underneath each of these resources, there is a flat list of resources.
Each resource is associated with a resource type (through the name of
the resource) and has two properties: resource type and resource super type.
d) we create a service which has three methods
// get the super type
String getResourceSuperType(ResourceResolver resolver, String resourceType);
// get an ordered list of all super types
List<String> getResourceSuperTypes(ResourceResolver resolver, String
resourceType)
// check if resourceType is checkResourceType (either directly or one of
the parents)
boolean isResourceType(ResourceResolver resolver, String resourceType,
String checkResourceType)
We pass in the resource resolver to this service in order to pass in the
search paths and the current user rights. This should allow us to
continue with this service, even if we add tenant support at a later
time or do some other checks.
With this approach we have
a) a clear resource type hierarchy which is stable. A resource of type A
has always the same resource super types. (unless the hierarchy is
changed of course)
b) the service reading the hierarchy only needs read access in a single
place
c) it's easy to find out the hierarchy by looking into the resource tree
d) the hierarchy can easily be cached in memory
WDYT?
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [RT] Improve resource type handling
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
I'm coming to this a bit late - I read the whole thread, hopefully got
the idea ;-)
On Fri, Mar 18, 2016 at 8:08 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...My rough initial proposal would be:
> a) forget about Resource#getResourceSuperType....
> b) the resource hierarchy is not spread across /libs, /apps anymore...
> c) we create a dedicated resource tree at /foo...
> d) we create a service which has three methods....
The whole thing looks a bit too big to me in terms of "small,
reversible changes" - would a simpler definition of those changes
work?
1) Forget about Resource#getResourceSuperType as you suggest - IOW
it's not the Resource which provides the resource type hierarchy
anymore
2) Create a service API that provides the resource type hierarchy
Am I correct that this is the core of your proposal?
If yes I think where 2) gets its info from can be seen as a separate
concern, or maybe as a second phase of these changes. Having minimal
changes initially should make it easier to figure out any backwards
compatibility issues.
-Bertrand
Re: [RT] Improve resource type handling
Posted by Georg Henzler <ge...@netcentric.biz>.
Hi,
I think it's a good idea to deprecate exotic use cases like defining
both resourceType and resourceSuperType on a content node. IMHO it is
a bad idea though to create a new location for scripts (e.g.
"/foo/apps"). Having scripts co-located with other artifacts (I don't
call it clutter) in /apps/myapp has never caused a problem in my
projects (they are easy to distinguish after all) - in fact another
aspect is a lot more important: Grouping of project artifacts should
first happen according business requirement/feature (e.g.
/apps/blog/blogpage) and then according technical aspects (scripts,
component descriptors etc. that belong to it). That way the
implementation of a feature is more cohesive, easier to understand and
undesired cross-references between features are easier to spot. In AEM
implementations we already have at least three locations where a
feature "blog page" would contribute: in apps, in /etc/designs and in
the corresponding java package - let's not open another location...
Regards
Georg
> On 19.03.2016, at 14:48, Justin Edelson <ju...@justinedelson.com> wrote:
>
> Hi,
>
> On Sat, Mar 19, 2016 at 6:11 AM Carsten Ziegeler <cz...@apache.org>
> wrote:
>
>> Justin Edelson wrote
>>>
>>> I guess I'm not really understanding the advantage of this flat list
>> (which
>>> wouldn't be a single flat list, but multiple flat lists). What is the the
>>> difference between
>>>
>>> /apps/myco/components/bar
>>> /libs/myco/components/bar
>>>
>>> and
>>>
>>> /foo/apps/myco:components:bar
>>> /foo/libs/myco:components:bar
>> With /foo you have resource type resources only, nothing else, no
>> clutter. It is true, that having /foo/apps and /foo/libs spoils the
>> whole thing and my initial idea was actually to just have
>> /foo/resourcetypehierarchy - no overlays for the resource type
>> hierarchy. But that would go against or overlay principle.
>
> In your mind, does /foo contain scripts inside the resource type resources?
>
>
>>
>> Maybe my idea is not the best, that's why it is an RT :) But I strongly
>> believe that we should move the hierarchy definition out of the /libs,
>> /apps bags of random stuff.
>
>
> I'm still not 100% sure I understand the problem, but it sounds to me like
> the better solution would be to move the random stuff out of /libs and
> /apps :) Unless I'm missing something (which is very possible), nothing
> would stop this same "random stuff" from showing up in /foo/libs and
> /foo/apps.
>
> It sounds like we need something like FHS (
> http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html). For better or
> worse, however, I think such a document needs to really encompass the scope
> of AEM (and possibly other downstream platforms based on Sling) to be truly
> meaningful.
>
> Regards,
> Justin
>
>
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
Re: [RT] Improve resource type handling
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi,
On Sat, Mar 19, 2016 at 6:11 AM Carsten Ziegeler <cz...@apache.org>
wrote:
> Justin Edelson wrote
> >
> > I guess I'm not really understanding the advantage of this flat list
> (which
> > wouldn't be a single flat list, but multiple flat lists). What is the the
> > difference between
> >
> > /apps/myco/components/bar
> > /libs/myco/components/bar
> >
> > and
> >
> > /foo/apps/myco:components:bar
> > /foo/libs/myco:components:bar
> >
> With /foo you have resource type resources only, nothing else, no
> clutter. It is true, that having /foo/apps and /foo/libs spoils the
> whole thing and my initial idea was actually to just have
> /foo/resourcetypehierarchy - no overlays for the resource type
> hierarchy. But that would go against or overlay principle.
>
In your mind, does /foo contain scripts inside the resource type resources?
>
> Maybe my idea is not the best, that's why it is an RT :) But I strongly
> believe that we should move the hierarchy definition out of the /libs,
> /apps bags of random stuff.
I'm still not 100% sure I understand the problem, but it sounds to me like
the better solution would be to move the random stuff out of /libs and
/apps :) Unless I'm missing something (which is very possible), nothing
would stop this same "random stuff" from showing up in /foo/libs and
/foo/apps.
It sounds like we need something like FHS (
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html). For better or
worse, however, I think such a document needs to really encompass the scope
of AEM (and possibly other downstream platforms based on Sling) to be truly
meaningful.
Regards,
Justin
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
Re: [RT] Improve resource type handling
Posted by Carsten Ziegeler <cz...@apache.org>.
Justin Edelson wrote
>
> I guess I'm not really understanding the advantage of this flat list (which
> wouldn't be a single flat list, but multiple flat lists). What is the the
> difference between
>
> /apps/myco/components/bar
> /libs/myco/components/bar
>
> and
>
> /foo/apps/myco:components:bar
> /foo/libs/myco:components:bar
>
With /foo you have resource type resources only, nothing else, no
clutter. It is true, that having /foo/apps and /foo/libs spoils the
whole thing and my initial idea was actually to just have
/foo/resourcetypehierarchy - no overlays for the resource type
hierarchy. But that would go against or overlay principle.
Maybe my idea is not the best, that's why it is an RT :) But I strongly
believe that we should move the hierarchy definition out of the /libs,
/apps bags of random stuff.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [RT] Improve resource type handling
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi,
On Fri, Mar 18, 2016 at 5:03 AM Carsten Ziegeler <cz...@apache.org>
wrote:
> Oliver Lietz wrote
> > On Friday 18 March 2016 08:08:55 Carsten Ziegeler wrote:
> >> Hi,
> >
> > Hi Carsten,
> >
> >> in the past years we added a lot of things here and there which over
> >> time resulted in cruft and sometimes hard to understand / debug
> >> problems. In order to have an even better framework which is easier to
> >> manage but also scales better for the things to come, we should get rid
> >> of this additional weigth.
> >>
> >> One area which I think needs attention is the resource type handling.
> >> We started years back with the two methods on a resource, getting a
> >> resource type and optionally getting a resource super type.
> >> A little bit later this was extended with what we call today the
> >> resource type hierarchy: for a resource type a/b, a resource can be
> >> created in /libs/a/b with a resource super type property. This can be
> >> overlayed in /apps. (I'm assuming the default search paths here to keep
> >> it simple).
> >>
> >> While this sounds nice and and simple, it has several drawbacks (in no
> >> particular order):
> >> - it's hard to find out all the super types of a resource type
> >> - the resource resolver which reads the type hierarchy needs read access
> >> to the complete tree of /libs and /apps - just to find a few properties
> >> here and there.
> >> - two resources with the same resource type, might have different
> >> resource super types or even a complete different hierarchy.
> >> - there is no guarantee that the resource super type is static, which
> >> means two calls to find the super type for a resource type could result
> >> in different results, e.g. if the resource itself decides to return a
> >> different value, or if a resource decorator is used which does so.
> >> - for traversing the hierarchy we currently create an additional admin
> >> resource resolver per resource resolver - which is a huge overhead.
> >>
> >> Especially the last three points make improving the script resolution
> >> hard - if not impossible. Today the cache is using the resource type and
> >> resource super type of the resource as a key. However, given the above
> >> information it is easy to create a scenario where the cache returns a
> >> wrong script.
> >>
> >> Taking all these things into account, I think we should somehow start
> >> fresh with handling the resource type hierarchy and come to a better
> >> solution. In this first step, I think we should not care about
> >> compatibility. Once we have a great solution, we'll find a way on how to
> >> achieve this.
> >>
> >> My rough initial proposal would be:
> >> a) forget about Resource#getResourceSuperType. This method is ignored
> >> from now on (and deprecated)
> >> b) the resource hierarchy is not spread across /libs, /apps anymore
> >> c) we create a dedicated resource tree at /foo (I'm using /foo as a
> >> placeholder as I don't want to start an endless discussion now on what
> >> this path actually really is). We then have /foo/apps and /foo/libs.
> >> Underneath each of these resources, there is a flat list of resources.
> >> Each resource is associated with a resource type (through the name of
> >> the resource) and has two properties: resource type and resource super
> type.
> >> d) we create a service which has three methods
> >>
> >> // get the super type
> >> String getResourceSuperType(ResourceResolver resolver, String
> resourceType);
> >> // get an ordered list of all super types
> >> List<String> getResourceSuperTypes(ResourceResolver resolver, String
> >> resourceType)
> >> // check if resourceType is checkResourceType (either directly or one of
> >> the parents)
> >> boolean isResourceType(ResourceResolver resolver, String resourceType,
> >> String checkResourceType)
> >>
> >> We pass in the resource resolver to this service in order to pass in the
> >> search paths and the current user rights. This should allow us to
> >> continue with this service, even if we add tenant support at a later
> >> time or do some other checks.
> >>
> >> With this approach we have
> >> a) a clear resource type hierarchy which is stable. A resource of type A
> >> has always the same resource super types. (unless the hierarchy is
> >> changed of course)
> >> b) the service reading the hierarchy only needs read access in a single
> >> place
> >> c) it's easy to find out the hierarchy by looking into the resource tree
> >> d) the hierarchy can easily be cached in memory
> >>
> >> WDYT?
> >
> > I don't get c): "flat list of resources" and "find out the hierarchy by
> > looking into the resource tree". Can you give an example?
> >
> Sure, assume you have a resource of type a/b - currently finding out all
> super types requires you too look at /apps/a/b, see if there is a resource
> super type property, do the same for /libs. Then use the found value and
> repeat
> the process until there is no such resource with a resource super type
> property.
> This can take a lot of time (sure you can write a script to do it)
>
> Now with a flat list at /foo/libs you'll find a /foo/libs/a:b resource
> (we have to find a mapping from path to name, but that should be
> doable), can look at the property - stay in the same place and do the
> next look up.
> It gets a little bit complicated as you have to look at /foo/apps and
> /foo/libs - but these are just two places compared to N.
>
I guess I'm not really understanding the advantage of this flat list (which
wouldn't be a single flat list, but multiple flat lists). What is the the
difference between
/apps/myco/components/bar
/libs/myco/components/bar
and
/foo/apps/myco:components:bar
/foo/libs/myco:components:bar
Regards,
Justin
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
Re: [RT] Improve resource type handling
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Klco wrote
> I like the proposal and definitely agree with the idea of deprecating
> Resource.getResourceSuperType(), it seems confusing and I've never seen it
> actually used.
>
> Just to confirm, regarding the flat list comment, you just mean that the
> list of components can be cached in a list structure, not that the
> hierarchy has to be flat, correct?
I was actually suggesting that the hierarchy is flat :) But maybe that's
not the best idea.
>
> Also, would it make sense to designate other structures like this for other
> parts of Sling applications? E.g. a dedicated folder for OSGi
> Configurations, installed bundles and application content? That would
> similarly reduce the amount of resources services would have to traverse
> and monitor for updates and would allow for much easier management of
> permissions.
>
Yepp, I think so
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [RT] Improve resource type handling
Posted by Daniel Klco <dk...@apache.org>.
I like the proposal and definitely agree with the idea of deprecating
Resource.getResourceSuperType(), it seems confusing and I've never seen it
actually used.
Just to confirm, regarding the flat list comment, you just mean that the
list of components can be cached in a list structure, not that the
hierarchy has to be flat, correct?
Also, would it make sense to designate other structures like this for other
parts of Sling applications? E.g. a dedicated folder for OSGi
Configurations, installed bundles and application content? That would
similarly reduce the amount of resources services would have to traverse
and monitor for updates and would allow for much easier management of
permissions.
On Fri, Mar 18, 2016 at 5:18 AM, Oliver Lietz <ap...@oliverlietz.de> wrote:
> On Friday 18 March 2016 10:03:17 Carsten Ziegeler wrote:
> > Oliver Lietz wrote
> >
> > > On Friday 18 March 2016 08:08:55 Carsten Ziegeler wrote:
> > >> Hi,
> > >
> > > Hi Carsten,
> > >
> > >> in the past years we added a lot of things here and there which over
> > >> time resulted in cruft and sometimes hard to understand / debug
> > >> problems. In order to have an even better framework which is easier to
> > >> manage but also scales better for the things to come, we should get
> rid
> > >> of this additional weigth.
> > >>
> > >> One area which I think needs attention is the resource type handling.
> > >> We started years back with the two methods on a resource, getting a
> > >> resource type and optionally getting a resource super type.
> > >> A little bit later this was extended with what we call today the
> > >> resource type hierarchy: for a resource type a/b, a resource can be
> > >> created in /libs/a/b with a resource super type property. This can be
> > >> overlayed in /apps. (I'm assuming the default search paths here to
> keep
> > >> it simple).
> > >>
> > >> While this sounds nice and and simple, it has several drawbacks (in no
> > >> particular order):
> > >> - it's hard to find out all the super types of a resource type
> > >> - the resource resolver which reads the type hierarchy needs read
> access
> > >> to the complete tree of /libs and /apps - just to find a few
> properties
> > >> here and there.
> > >> - two resources with the same resource type, might have different
> > >> resource super types or even a complete different hierarchy.
> > >> - there is no guarantee that the resource super type is static, which
> > >> means two calls to find the super type for a resource type could
> result
> > >> in different results, e.g. if the resource itself decides to return a
> > >> different value, or if a resource decorator is used which does so.
> > >> - for traversing the hierarchy we currently create an additional admin
> > >> resource resolver per resource resolver - which is a huge overhead.
> > >>
> > >> Especially the last three points make improving the script resolution
> > >> hard - if not impossible. Today the cache is using the resource type
> and
> > >> resource super type of the resource as a key. However, given the above
> > >> information it is easy to create a scenario where the cache returns a
> > >> wrong script.
> > >>
> > >> Taking all these things into account, I think we should somehow start
> > >> fresh with handling the resource type hierarchy and come to a better
> > >> solution. In this first step, I think we should not care about
> > >> compatibility. Once we have a great solution, we'll find a way on how
> to
> > >> achieve this.
> > >>
> > >> My rough initial proposal would be:
> > >> a) forget about Resource#getResourceSuperType. This method is ignored
> > >> from now on (and deprecated)
> > >> b) the resource hierarchy is not spread across /libs, /apps anymore
> > >> c) we create a dedicated resource tree at /foo (I'm using /foo as a
> > >> placeholder as I don't want to start an endless discussion now on what
> > >> this path actually really is). We then have /foo/apps and /foo/libs.
> > >> Underneath each of these resources, there is a flat list of resources.
> > >> Each resource is associated with a resource type (through the name of
> > >> the resource) and has two properties: resource type and resource super
> > >> type. d) we create a service which has three methods
> > >>
> > >> // get the super type
> > >> String getResourceSuperType(ResourceResolver resolver, String
> > >> resourceType); // get an ordered list of all super types
> > >> List<String> getResourceSuperTypes(ResourceResolver resolver, String
> > >> resourceType)
> > >> // check if resourceType is checkResourceType (either directly or one
> of
> > >> the parents)
> > >> boolean isResourceType(ResourceResolver resolver, String resourceType,
> > >> String checkResourceType)
> > >>
> > >> We pass in the resource resolver to this service in order to pass in
> the
> > >> search paths and the current user rights. This should allow us to
> > >> continue with this service, even if we add tenant support at a later
> > >> time or do some other checks.
> > >>
> > >> With this approach we have
> > >> a) a clear resource type hierarchy which is stable. A resource of
> type A
> > >> has always the same resource super types. (unless the hierarchy is
> > >> changed of course)
> > >> b) the service reading the hierarchy only needs read access in a
> single
> > >> place
> > >> c) it's easy to find out the hierarchy by looking into the resource
> tree
> > >> d) the hierarchy can easily be cached in memory
> > >>
> > >> WDYT?
> > >
> > > I don't get c): "flat list of resources" and "find out the hierarchy by
> > > looking into the resource tree". Can you give an example?
> >
> > Sure, assume you have a resource of type a/b - currently finding out all
> > super types requires you too look at /apps/a/b, see if there is a
> resource
> > super type property, do the same for /libs. Then use the found value and
> > repeat
> > the process until there is no such resource with a resource super type
> > property.
> > This can take a lot of time (sure you can write a script to do it)
> >
> > Now with a flat list at /foo/libs you'll find a /foo/libs/a:b resource
> > (we have to find a mapping from path to name, but that should be
> > doable), can look at the property - stay in the same place and do the
> > next look up.
> > It gets a little bit complicated as you have to look at /foo/apps and
> > /foo/libs - but these are just two places compared to N.
>
> "(we have to find a mapping from path to name, but that should be
> doable)" – that was the missing piece, thanks.
>
> O.
>
> > Regards
> > Carsten
>
>
Re: [RT] Improve resource type handling
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Friday 18 March 2016 10:03:17 Carsten Ziegeler wrote:
> Oliver Lietz wrote
>
> > On Friday 18 March 2016 08:08:55 Carsten Ziegeler wrote:
> >> Hi,
> >
> > Hi Carsten,
> >
> >> in the past years we added a lot of things here and there which over
> >> time resulted in cruft and sometimes hard to understand / debug
> >> problems. In order to have an even better framework which is easier to
> >> manage but also scales better for the things to come, we should get rid
> >> of this additional weigth.
> >>
> >> One area which I think needs attention is the resource type handling.
> >> We started years back with the two methods on a resource, getting a
> >> resource type and optionally getting a resource super type.
> >> A little bit later this was extended with what we call today the
> >> resource type hierarchy: for a resource type a/b, a resource can be
> >> created in /libs/a/b with a resource super type property. This can be
> >> overlayed in /apps. (I'm assuming the default search paths here to keep
> >> it simple).
> >>
> >> While this sounds nice and and simple, it has several drawbacks (in no
> >> particular order):
> >> - it's hard to find out all the super types of a resource type
> >> - the resource resolver which reads the type hierarchy needs read access
> >> to the complete tree of /libs and /apps - just to find a few properties
> >> here and there.
> >> - two resources with the same resource type, might have different
> >> resource super types or even a complete different hierarchy.
> >> - there is no guarantee that the resource super type is static, which
> >> means two calls to find the super type for a resource type could result
> >> in different results, e.g. if the resource itself decides to return a
> >> different value, or if a resource decorator is used which does so.
> >> - for traversing the hierarchy we currently create an additional admin
> >> resource resolver per resource resolver - which is a huge overhead.
> >>
> >> Especially the last three points make improving the script resolution
> >> hard - if not impossible. Today the cache is using the resource type and
> >> resource super type of the resource as a key. However, given the above
> >> information it is easy to create a scenario where the cache returns a
> >> wrong script.
> >>
> >> Taking all these things into account, I think we should somehow start
> >> fresh with handling the resource type hierarchy and come to a better
> >> solution. In this first step, I think we should not care about
> >> compatibility. Once we have a great solution, we'll find a way on how to
> >> achieve this.
> >>
> >> My rough initial proposal would be:
> >> a) forget about Resource#getResourceSuperType. This method is ignored
> >> from now on (and deprecated)
> >> b) the resource hierarchy is not spread across /libs, /apps anymore
> >> c) we create a dedicated resource tree at /foo (I'm using /foo as a
> >> placeholder as I don't want to start an endless discussion now on what
> >> this path actually really is). We then have /foo/apps and /foo/libs.
> >> Underneath each of these resources, there is a flat list of resources.
> >> Each resource is associated with a resource type (through the name of
> >> the resource) and has two properties: resource type and resource super
> >> type. d) we create a service which has three methods
> >>
> >> // get the super type
> >> String getResourceSuperType(ResourceResolver resolver, String
> >> resourceType); // get an ordered list of all super types
> >> List<String> getResourceSuperTypes(ResourceResolver resolver, String
> >> resourceType)
> >> // check if resourceType is checkResourceType (either directly or one of
> >> the parents)
> >> boolean isResourceType(ResourceResolver resolver, String resourceType,
> >> String checkResourceType)
> >>
> >> We pass in the resource resolver to this service in order to pass in the
> >> search paths and the current user rights. This should allow us to
> >> continue with this service, even if we add tenant support at a later
> >> time or do some other checks.
> >>
> >> With this approach we have
> >> a) a clear resource type hierarchy which is stable. A resource of type A
> >> has always the same resource super types. (unless the hierarchy is
> >> changed of course)
> >> b) the service reading the hierarchy only needs read access in a single
> >> place
> >> c) it's easy to find out the hierarchy by looking into the resource tree
> >> d) the hierarchy can easily be cached in memory
> >>
> >> WDYT?
> >
> > I don't get c): "flat list of resources" and "find out the hierarchy by
> > looking into the resource tree". Can you give an example?
>
> Sure, assume you have a resource of type a/b - currently finding out all
> super types requires you too look at /apps/a/b, see if there is a resource
> super type property, do the same for /libs. Then use the found value and
> repeat
> the process until there is no such resource with a resource super type
> property.
> This can take a lot of time (sure you can write a script to do it)
>
> Now with a flat list at /foo/libs you'll find a /foo/libs/a:b resource
> (we have to find a mapping from path to name, but that should be
> doable), can look at the property - stay in the same place and do the
> next look up.
> It gets a little bit complicated as you have to look at /foo/apps and
> /foo/libs - but these are just two places compared to N.
"(we have to find a mapping from path to name, but that should be
doable)" – that was the missing piece, thanks.
O.
> Regards
> Carsten
Re: [RT] Improve resource type handling
Posted by Carsten Ziegeler <cz...@apache.org>.
Oliver Lietz wrote
> On Friday 18 March 2016 08:08:55 Carsten Ziegeler wrote:
>> Hi,
>
> Hi Carsten,
>
>> in the past years we added a lot of things here and there which over
>> time resulted in cruft and sometimes hard to understand / debug
>> problems. In order to have an even better framework which is easier to
>> manage but also scales better for the things to come, we should get rid
>> of this additional weigth.
>>
>> One area which I think needs attention is the resource type handling.
>> We started years back with the two methods on a resource, getting a
>> resource type and optionally getting a resource super type.
>> A little bit later this was extended with what we call today the
>> resource type hierarchy: for a resource type a/b, a resource can be
>> created in /libs/a/b with a resource super type property. This can be
>> overlayed in /apps. (I'm assuming the default search paths here to keep
>> it simple).
>>
>> While this sounds nice and and simple, it has several drawbacks (in no
>> particular order):
>> - it's hard to find out all the super types of a resource type
>> - the resource resolver which reads the type hierarchy needs read access
>> to the complete tree of /libs and /apps - just to find a few properties
>> here and there.
>> - two resources with the same resource type, might have different
>> resource super types or even a complete different hierarchy.
>> - there is no guarantee that the resource super type is static, which
>> means two calls to find the super type for a resource type could result
>> in different results, e.g. if the resource itself decides to return a
>> different value, or if a resource decorator is used which does so.
>> - for traversing the hierarchy we currently create an additional admin
>> resource resolver per resource resolver - which is a huge overhead.
>>
>> Especially the last three points make improving the script resolution
>> hard - if not impossible. Today the cache is using the resource type and
>> resource super type of the resource as a key. However, given the above
>> information it is easy to create a scenario where the cache returns a
>> wrong script.
>>
>> Taking all these things into account, I think we should somehow start
>> fresh with handling the resource type hierarchy and come to a better
>> solution. In this first step, I think we should not care about
>> compatibility. Once we have a great solution, we'll find a way on how to
>> achieve this.
>>
>> My rough initial proposal would be:
>> a) forget about Resource#getResourceSuperType. This method is ignored
>> from now on (and deprecated)
>> b) the resource hierarchy is not spread across /libs, /apps anymore
>> c) we create a dedicated resource tree at /foo (I'm using /foo as a
>> placeholder as I don't want to start an endless discussion now on what
>> this path actually really is). We then have /foo/apps and /foo/libs.
>> Underneath each of these resources, there is a flat list of resources.
>> Each resource is associated with a resource type (through the name of
>> the resource) and has two properties: resource type and resource super type.
>> d) we create a service which has three methods
>>
>> // get the super type
>> String getResourceSuperType(ResourceResolver resolver, String resourceType);
>> // get an ordered list of all super types
>> List<String> getResourceSuperTypes(ResourceResolver resolver, String
>> resourceType)
>> // check if resourceType is checkResourceType (either directly or one of
>> the parents)
>> boolean isResourceType(ResourceResolver resolver, String resourceType,
>> String checkResourceType)
>>
>> We pass in the resource resolver to this service in order to pass in the
>> search paths and the current user rights. This should allow us to
>> continue with this service, even if we add tenant support at a later
>> time or do some other checks.
>>
>> With this approach we have
>> a) a clear resource type hierarchy which is stable. A resource of type A
>> has always the same resource super types. (unless the hierarchy is
>> changed of course)
>> b) the service reading the hierarchy only needs read access in a single
>> place
>> c) it's easy to find out the hierarchy by looking into the resource tree
>> d) the hierarchy can easily be cached in memory
>>
>> WDYT?
>
> I don't get c): "flat list of resources" and "find out the hierarchy by
> looking into the resource tree". Can you give an example?
>
Sure, assume you have a resource of type a/b - currently finding out all
super types requires you too look at /apps/a/b, see if there is a resource
super type property, do the same for /libs. Then use the found value and
repeat
the process until there is no such resource with a resource super type
property.
This can take a lot of time (sure you can write a script to do it)
Now with a flat list at /foo/libs you'll find a /foo/libs/a:b resource
(we have to find a mapping from path to name, but that should be
doable), can look at the property - stay in the same place and do the
next look up.
It gets a little bit complicated as you have to look at /foo/apps and
/foo/libs - but these are just two places compared to N.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [RT] Improve resource type handling
Posted by Julian Sedding <js...@gmail.com>.
I agree with removing Resource.getResourceSuperType() (i.e. Carsten's
original point a)), and the usage (or interpretation) of the
"sling:resourceSuperType" property on content nodes (i.e. nodes
located outside the search path(s)). This should lead to a stable
hierarchy that is cacheable.
Also, providing a service to access the resource type hierarchy (that
allows caching) is IMHO a good idea (i.e. Carsten's original point
d)). We need to find adequate API signatures, but let's assume we can
achieve that ;)
However, currently I do not agree with moving the definition of the
hierarchy to a dedicated location (i.e. Carsten's original points b)
and c)).
In order to make it easier to inspect the hierarchy (i.e. Carsten
wrote "it's easy to find out the hierarchy by looking into the
resource tree"), we could let the service expose the resource
hierarchy as a resource tree (ResourceProvider), powered by the same
in-memory cache that the service might use. Alternatively, a
consolidated tree could be automatically written into the repository
and the service could use that to initialize its cache. (My preference
would be the former, because keeping two physical structures in sync
is error prone).
Regards
Julian
On Mon, Mar 21, 2016 at 1:28 PM, Jason Bailey <Ja...@sas.com> wrote:
> There is a third use case from a presentation perspective, which is the 'is a' use case. Is this resource a resource of resource type 'foo'
>
> -----Original Message-----
> From: Konrad Windszus [mailto:konrad_w@gmx.de]
> Sent: Friday, March 18, 2016 4:42 AM
> To: dev@sling.apache.org
> Subject: Re: [RT] Improve resource type handling
>
> For me it would help a lot to quickly reconsider the current situation.
> As far as I know resource super types are used for two different things in Sling right now:
>
> 1. Script resolution: Influences which script is being picked up (initially or via includes from other scripts), documented in https://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html#base-resource-type-inheritance
> 2. Resource merging: For the override resource merger (http://sling.staging.apache.org/documentation/bundles/resource-merger.html#overriding-resource-picker-override-approach)
>
> The problem is that for 1. the resource super type may be defined at two different locations:
> a) having a sling:resourceSuperType property in the node referencing the resource type
> b) having a sling:resourceSuperType property in the node addressed by the resource type compare with https://issues.apache.org/jira/browse/SLING-278.
>
> a) is really confusing because a) may overwrite b) and that resource type inheritance is used only for script resolution. To simplify thing I would suggest to just get rid of a). Who is using a)?
>
> Regarding the proposal having a dedicated resource subtree where the inheritance would be declared sounds overly complicated to me. It feels much more natural to define the super type directly on the resource implementing a certain resource type.
>
> For content merging it would feel more natural to have a generic resource inheritance concept. So something like "superResource" (rather than resourceSuperType).
> That way it feels more natural that this may be used for 1. only on resources implementing a resource type and 2. for resources defining some content.
> I would expect that this super resource is always defined on the resource to which it applies (not in a dedicated part of the resource tree).
>
> WDYT?
> Konrad
>
>
>
>
>> On 18 Mar 2016, at 09:09, Oliver Lietz <ap...@oliverlietz.de> wrote:
>>
>> On Friday 18 March 2016 08:08:55 Carsten Ziegeler wrote:
>>> Hi,
>>
>> Hi Carsten,
>>
>>> in the past years we added a lot of things here and there which over
>>> time resulted in cruft and sometimes hard to understand / debug
>>> problems. In order to have an even better framework which is easier
>>> to manage but also scales better for the things to come, we should
>>> get rid of this additional weigth.
>>>
>>> One area which I think needs attention is the resource type handling.
>>> We started years back with the two methods on a resource, getting a
>>> resource type and optionally getting a resource super type.
>>> A little bit later this was extended with what we call today the
>>> resource type hierarchy: for a resource type a/b, a resource can be
>>> created in /libs/a/b with a resource super type property. This can be
>>> overlayed in /apps. (I'm assuming the default search paths here to
>>> keep it simple).
>>>
>>> While this sounds nice and and simple, it has several drawbacks (in
>>> no particular order):
>>> - it's hard to find out all the super types of a resource type
>>> - the resource resolver which reads the type hierarchy needs read
>>> access to the complete tree of /libs and /apps - just to find a few
>>> properties here and there.
>>> - two resources with the same resource type, might have different
>>> resource super types or even a complete different hierarchy.
>>> - there is no guarantee that the resource super type is static, which
>>> means two calls to find the super type for a resource type could
>>> result in different results, e.g. if the resource itself decides to
>>> return a different value, or if a resource decorator is used which does so.
>>> - for traversing the hierarchy we currently create an additional
>>> admin resource resolver per resource resolver - which is a huge overhead.
>>>
>>> Especially the last three points make improving the script resolution
>>> hard - if not impossible. Today the cache is using the resource type
>>> and resource super type of the resource as a key. However, given the
>>> above information it is easy to create a scenario where the cache
>>> returns a wrong script.
>>>
>>> Taking all these things into account, I think we should somehow start
>>> fresh with handling the resource type hierarchy and come to a better
>>> solution. In this first step, I think we should not care about
>>> compatibility. Once we have a great solution, we'll find a way on how
>>> to achieve this.
>>>
>>> My rough initial proposal would be:
>>> a) forget about Resource#getResourceSuperType. This method is ignored
>>> from now on (and deprecated)
>>> b) the resource hierarchy is not spread across /libs, /apps anymore
>>> c) we create a dedicated resource tree at /foo (I'm using /foo as a
>>> placeholder as I don't want to start an endless discussion now on
>>> what this path actually really is). We then have /foo/apps and /foo/libs.
>>> Underneath each of these resources, there is a flat list of resources.
>>> Each resource is associated with a resource type (through the name of
>>> the resource) and has two properties: resource type and resource super type.
>>> d) we create a service which has three methods
>>>
>>> // get the super type
>>> String getResourceSuperType(ResourceResolver resolver, String
>>> resourceType); // get an ordered list of all super types List<String>
>>> getResourceSuperTypes(ResourceResolver resolver, String
>>> resourceType)
>>> // check if resourceType is checkResourceType (either directly or one
>>> of the parents) boolean isResourceType(ResourceResolver resolver,
>>> String resourceType, String checkResourceType)
>>>
>>> We pass in the resource resolver to this service in order to pass in
>>> the search paths and the current user rights. This should allow us to
>>> continue with this service, even if we add tenant support at a later
>>> time or do some other checks.
>>>
>>> With this approach we have
>>> a) a clear resource type hierarchy which is stable. A resource of
>>> type A has always the same resource super types. (unless the
>>> hierarchy is changed of course)
>>> b) the service reading the hierarchy only needs read access in a
>>> single place
>>> c) it's easy to find out the hierarchy by looking into the resource
>>> tree
>>> d) the hierarchy can easily be cached in memory
>>>
>>> WDYT?
>>
>> I don't get c): "flat list of resources" and "find out the hierarchy
>> by looking into the resource tree". Can you give an example?
>>
>> Thanks,
>> O.
>>
>>> Regards
>>> Carsten
>>
>>
>
RE: [RT] Improve resource type handling
Posted by Jason Bailey <Ja...@sas.com>.
There is a third use case from a presentation perspective, which is the 'is a' use case. Is this resource a resource of resource type 'foo'
-----Original Message-----
From: Konrad Windszus [mailto:konrad_w@gmx.de]
Sent: Friday, March 18, 2016 4:42 AM
To: dev@sling.apache.org
Subject: Re: [RT] Improve resource type handling
For me it would help a lot to quickly reconsider the current situation.
As far as I know resource super types are used for two different things in Sling right now:
1. Script resolution: Influences which script is being picked up (initially or via includes from other scripts), documented in https://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html#base-resource-type-inheritance
2. Resource merging: For the override resource merger (http://sling.staging.apache.org/documentation/bundles/resource-merger.html#overriding-resource-picker-override-approach)
The problem is that for 1. the resource super type may be defined at two different locations:
a) having a sling:resourceSuperType property in the node referencing the resource type
b) having a sling:resourceSuperType property in the node addressed by the resource type compare with https://issues.apache.org/jira/browse/SLING-278.
a) is really confusing because a) may overwrite b) and that resource type inheritance is used only for script resolution. To simplify thing I would suggest to just get rid of a). Who is using a)?
Regarding the proposal having a dedicated resource subtree where the inheritance would be declared sounds overly complicated to me. It feels much more natural to define the super type directly on the resource implementing a certain resource type.
For content merging it would feel more natural to have a generic resource inheritance concept. So something like "superResource" (rather than resourceSuperType).
That way it feels more natural that this may be used for 1. only on resources implementing a resource type and 2. for resources defining some content.
I would expect that this super resource is always defined on the resource to which it applies (not in a dedicated part of the resource tree).
WDYT?
Konrad
> On 18 Mar 2016, at 09:09, Oliver Lietz <ap...@oliverlietz.de> wrote:
>
> On Friday 18 March 2016 08:08:55 Carsten Ziegeler wrote:
>> Hi,
>
> Hi Carsten,
>
>> in the past years we added a lot of things here and there which over
>> time resulted in cruft and sometimes hard to understand / debug
>> problems. In order to have an even better framework which is easier
>> to manage but also scales better for the things to come, we should
>> get rid of this additional weigth.
>>
>> One area which I think needs attention is the resource type handling.
>> We started years back with the two methods on a resource, getting a
>> resource type and optionally getting a resource super type.
>> A little bit later this was extended with what we call today the
>> resource type hierarchy: for a resource type a/b, a resource can be
>> created in /libs/a/b with a resource super type property. This can be
>> overlayed in /apps. (I'm assuming the default search paths here to
>> keep it simple).
>>
>> While this sounds nice and and simple, it has several drawbacks (in
>> no particular order):
>> - it's hard to find out all the super types of a resource type
>> - the resource resolver which reads the type hierarchy needs read
>> access to the complete tree of /libs and /apps - just to find a few
>> properties here and there.
>> - two resources with the same resource type, might have different
>> resource super types or even a complete different hierarchy.
>> - there is no guarantee that the resource super type is static, which
>> means two calls to find the super type for a resource type could
>> result in different results, e.g. if the resource itself decides to
>> return a different value, or if a resource decorator is used which does so.
>> - for traversing the hierarchy we currently create an additional
>> admin resource resolver per resource resolver - which is a huge overhead.
>>
>> Especially the last three points make improving the script resolution
>> hard - if not impossible. Today the cache is using the resource type
>> and resource super type of the resource as a key. However, given the
>> above information it is easy to create a scenario where the cache
>> returns a wrong script.
>>
>> Taking all these things into account, I think we should somehow start
>> fresh with handling the resource type hierarchy and come to a better
>> solution. In this first step, I think we should not care about
>> compatibility. Once we have a great solution, we'll find a way on how
>> to achieve this.
>>
>> My rough initial proposal would be:
>> a) forget about Resource#getResourceSuperType. This method is ignored
>> from now on (and deprecated)
>> b) the resource hierarchy is not spread across /libs, /apps anymore
>> c) we create a dedicated resource tree at /foo (I'm using /foo as a
>> placeholder as I don't want to start an endless discussion now on
>> what this path actually really is). We then have /foo/apps and /foo/libs.
>> Underneath each of these resources, there is a flat list of resources.
>> Each resource is associated with a resource type (through the name of
>> the resource) and has two properties: resource type and resource super type.
>> d) we create a service which has three methods
>>
>> // get the super type
>> String getResourceSuperType(ResourceResolver resolver, String
>> resourceType); // get an ordered list of all super types List<String>
>> getResourceSuperTypes(ResourceResolver resolver, String
>> resourceType)
>> // check if resourceType is checkResourceType (either directly or one
>> of the parents) boolean isResourceType(ResourceResolver resolver,
>> String resourceType, String checkResourceType)
>>
>> We pass in the resource resolver to this service in order to pass in
>> the search paths and the current user rights. This should allow us to
>> continue with this service, even if we add tenant support at a later
>> time or do some other checks.
>>
>> With this approach we have
>> a) a clear resource type hierarchy which is stable. A resource of
>> type A has always the same resource super types. (unless the
>> hierarchy is changed of course)
>> b) the service reading the hierarchy only needs read access in a
>> single place
>> c) it's easy to find out the hierarchy by looking into the resource
>> tree
>> d) the hierarchy can easily be cached in memory
>>
>> WDYT?
>
> I don't get c): "flat list of resources" and "find out the hierarchy
> by looking into the resource tree". Can you give an example?
>
> Thanks,
> O.
>
>> Regards
>> Carsten
>
>
Re: [RT] Improve resource type handling
Posted by Carsten Ziegeler <cz...@apache.org>.
Konrad Windszus wrote
> For me it would help a lot to quickly reconsider the current situation.
> As far as I know resource super types are used for two different things in Sling right now:
>
> 1. Script resolution: Influences which script is being picked up (initially or via includes from other scripts), documented in https://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html#base-resource-type-inheritance
> 2. Resource merging: For the override resource merger (http://sling.staging.apache.org/documentation/bundles/resource-merger.html#overriding-resource-picker-override-approach)
>
> The problem is that for 1. the resource super type may be defined at two different locations:
> a) having a sling:resourceSuperType property in the node referencing the resource type
> b) having a sling:resourceSuperType property in the node addressed by the resource type
> compare with https://issues.apache.org/jira/browse/SLING-278.
>
> a) is really confusing because a) may overwrite b) and that resource type inheritance is used only for script resolution. To simplify thing I would suggest to just get rid of a). Who is using a)?
>
Thats part of my proposal.
> Regarding the proposal having a dedicated resource subtree where the inheritance would be declared sounds overly complicated to me. It feels much more natural to define the super type directly on the resource implementing a certain resource type.
I see it differently :) It right now complicates everything. I would
also try to move the scripts out of /libs, /apps. There is a lot of
things in these trees. If you think of operation systems, you have a
search path for your commands, and each path only contains scripts but
not all the additional stuff.
>
> For content merging it would feel more natural to have a generic resource inheritance concept. So something like "superResource" (rather than resourceSuperType).
> That way it feels more natural that this may be used for 1. only on resources implementing a resource type and 2. for resources defining some content.
> I would expect that this super resource is always defined on the resource to which it applies (not in a dedicated part of the resource tree).
>
I haven't looked into the resource merging use case, as this has been
added on top of the already complicated mechanism
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [RT] Improve resource type handling
Posted by Konrad Windszus <ko...@gmx.de>.
For me it would help a lot to quickly reconsider the current situation.
As far as I know resource super types are used for two different things in Sling right now:
1. Script resolution: Influences which script is being picked up (initially or via includes from other scripts), documented in https://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html#base-resource-type-inheritance
2. Resource merging: For the override resource merger (http://sling.staging.apache.org/documentation/bundles/resource-merger.html#overriding-resource-picker-override-approach)
The problem is that for 1. the resource super type may be defined at two different locations:
a) having a sling:resourceSuperType property in the node referencing the resource type
b) having a sling:resourceSuperType property in the node addressed by the resource type
compare with https://issues.apache.org/jira/browse/SLING-278.
a) is really confusing because a) may overwrite b) and that resource type inheritance is used only for script resolution. To simplify thing I would suggest to just get rid of a). Who is using a)?
Regarding the proposal having a dedicated resource subtree where the inheritance would be declared sounds overly complicated to me. It feels much more natural to define the super type directly on the resource implementing a certain resource type.
For content merging it would feel more natural to have a generic resource inheritance concept. So something like "superResource" (rather than resourceSuperType).
That way it feels more natural that this may be used for 1. only on resources implementing a resource type and 2. for resources defining some content.
I would expect that this super resource is always defined on the resource to which it applies (not in a dedicated part of the resource tree).
WDYT?
Konrad
> On 18 Mar 2016, at 09:09, Oliver Lietz <ap...@oliverlietz.de> wrote:
>
> On Friday 18 March 2016 08:08:55 Carsten Ziegeler wrote:
>> Hi,
>
> Hi Carsten,
>
>> in the past years we added a lot of things here and there which over
>> time resulted in cruft and sometimes hard to understand / debug
>> problems. In order to have an even better framework which is easier to
>> manage but also scales better for the things to come, we should get rid
>> of this additional weigth.
>>
>> One area which I think needs attention is the resource type handling.
>> We started years back with the two methods on a resource, getting a
>> resource type and optionally getting a resource super type.
>> A little bit later this was extended with what we call today the
>> resource type hierarchy: for a resource type a/b, a resource can be
>> created in /libs/a/b with a resource super type property. This can be
>> overlayed in /apps. (I'm assuming the default search paths here to keep
>> it simple).
>>
>> While this sounds nice and and simple, it has several drawbacks (in no
>> particular order):
>> - it's hard to find out all the super types of a resource type
>> - the resource resolver which reads the type hierarchy needs read access
>> to the complete tree of /libs and /apps - just to find a few properties
>> here and there.
>> - two resources with the same resource type, might have different
>> resource super types or even a complete different hierarchy.
>> - there is no guarantee that the resource super type is static, which
>> means two calls to find the super type for a resource type could result
>> in different results, e.g. if the resource itself decides to return a
>> different value, or if a resource decorator is used which does so.
>> - for traversing the hierarchy we currently create an additional admin
>> resource resolver per resource resolver - which is a huge overhead.
>>
>> Especially the last three points make improving the script resolution
>> hard - if not impossible. Today the cache is using the resource type and
>> resource super type of the resource as a key. However, given the above
>> information it is easy to create a scenario where the cache returns a
>> wrong script.
>>
>> Taking all these things into account, I think we should somehow start
>> fresh with handling the resource type hierarchy and come to a better
>> solution. In this first step, I think we should not care about
>> compatibility. Once we have a great solution, we'll find a way on how to
>> achieve this.
>>
>> My rough initial proposal would be:
>> a) forget about Resource#getResourceSuperType. This method is ignored
>> from now on (and deprecated)
>> b) the resource hierarchy is not spread across /libs, /apps anymore
>> c) we create a dedicated resource tree at /foo (I'm using /foo as a
>> placeholder as I don't want to start an endless discussion now on what
>> this path actually really is). We then have /foo/apps and /foo/libs.
>> Underneath each of these resources, there is a flat list of resources.
>> Each resource is associated with a resource type (through the name of
>> the resource) and has two properties: resource type and resource super type.
>> d) we create a service which has three methods
>>
>> // get the super type
>> String getResourceSuperType(ResourceResolver resolver, String resourceType);
>> // get an ordered list of all super types
>> List<String> getResourceSuperTypes(ResourceResolver resolver, String
>> resourceType)
>> // check if resourceType is checkResourceType (either directly or one of
>> the parents)
>> boolean isResourceType(ResourceResolver resolver, String resourceType,
>> String checkResourceType)
>>
>> We pass in the resource resolver to this service in order to pass in the
>> search paths and the current user rights. This should allow us to
>> continue with this service, even if we add tenant support at a later
>> time or do some other checks.
>>
>> With this approach we have
>> a) a clear resource type hierarchy which is stable. A resource of type A
>> has always the same resource super types. (unless the hierarchy is
>> changed of course)
>> b) the service reading the hierarchy only needs read access in a single
>> place
>> c) it's easy to find out the hierarchy by looking into the resource tree
>> d) the hierarchy can easily be cached in memory
>>
>> WDYT?
>
> I don't get c): "flat list of resources" and "find out the hierarchy by
> looking into the resource tree". Can you give an example?
>
> Thanks,
> O.
>
>> Regards
>> Carsten
>
>
Re: [RT] Improve resource type handling
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Friday 18 March 2016 08:08:55 Carsten Ziegeler wrote:
> Hi,
Hi Carsten,
> in the past years we added a lot of things here and there which over
> time resulted in cruft and sometimes hard to understand / debug
> problems. In order to have an even better framework which is easier to
> manage but also scales better for the things to come, we should get rid
> of this additional weigth.
>
> One area which I think needs attention is the resource type handling.
> We started years back with the two methods on a resource, getting a
> resource type and optionally getting a resource super type.
> A little bit later this was extended with what we call today the
> resource type hierarchy: for a resource type a/b, a resource can be
> created in /libs/a/b with a resource super type property. This can be
> overlayed in /apps. (I'm assuming the default search paths here to keep
> it simple).
>
> While this sounds nice and and simple, it has several drawbacks (in no
> particular order):
> - it's hard to find out all the super types of a resource type
> - the resource resolver which reads the type hierarchy needs read access
> to the complete tree of /libs and /apps - just to find a few properties
> here and there.
> - two resources with the same resource type, might have different
> resource super types or even a complete different hierarchy.
> - there is no guarantee that the resource super type is static, which
> means two calls to find the super type for a resource type could result
> in different results, e.g. if the resource itself decides to return a
> different value, or if a resource decorator is used which does so.
> - for traversing the hierarchy we currently create an additional admin
> resource resolver per resource resolver - which is a huge overhead.
>
> Especially the last three points make improving the script resolution
> hard - if not impossible. Today the cache is using the resource type and
> resource super type of the resource as a key. However, given the above
> information it is easy to create a scenario where the cache returns a
> wrong script.
>
> Taking all these things into account, I think we should somehow start
> fresh with handling the resource type hierarchy and come to a better
> solution. In this first step, I think we should not care about
> compatibility. Once we have a great solution, we'll find a way on how to
> achieve this.
>
> My rough initial proposal would be:
> a) forget about Resource#getResourceSuperType. This method is ignored
> from now on (and deprecated)
> b) the resource hierarchy is not spread across /libs, /apps anymore
> c) we create a dedicated resource tree at /foo (I'm using /foo as a
> placeholder as I don't want to start an endless discussion now on what
> this path actually really is). We then have /foo/apps and /foo/libs.
> Underneath each of these resources, there is a flat list of resources.
> Each resource is associated with a resource type (through the name of
> the resource) and has two properties: resource type and resource super type.
> d) we create a service which has three methods
>
> // get the super type
> String getResourceSuperType(ResourceResolver resolver, String resourceType);
> // get an ordered list of all super types
> List<String> getResourceSuperTypes(ResourceResolver resolver, String
> resourceType)
> // check if resourceType is checkResourceType (either directly or one of
> the parents)
> boolean isResourceType(ResourceResolver resolver, String resourceType,
> String checkResourceType)
>
> We pass in the resource resolver to this service in order to pass in the
> search paths and the current user rights. This should allow us to
> continue with this service, even if we add tenant support at a later
> time or do some other checks.
>
> With this approach we have
> a) a clear resource type hierarchy which is stable. A resource of type A
> has always the same resource super types. (unless the hierarchy is
> changed of course)
> b) the service reading the hierarchy only needs read access in a single
> place
> c) it's easy to find out the hierarchy by looking into the resource tree
> d) the hierarchy can easily be cached in memory
>
> WDYT?
I don't get c): "flat list of resources" and "find out the hierarchy by
looking into the resource tree". Can you give an example?
Thanks,
O.
> Regards
> Carsten
Re: [RT] Improve resource type handling
Posted by Carsten Ziegeler <cz...@apache.org>.
Roy Teeuwen wrote
> I know I am talking out of AEM experience, but I don’t see why one would only go for a flat resourceSuperType list?
>
> The most simple example here where that would have massive consequences is in how you would build a page.
> At this moment you have a basepage, and X child pages which all have the basepage as resouceSuperType, inheriting everything from header to footer. Why would you ever want to break this ideal setup?
>
Maybe my description was misleading :) I want to store the hierarchy in
a flat way, the hierarchy itself works as before. There is nothing wrong
with it. But as I said maybe this idea is too crazy.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [RT] Improve resource type handling
Posted by Roy Teeuwen <ro...@teeuwen.be>.
I know I am talking out of AEM experience, but I don’t see why one would only go for a flat resourceSuperType list?
The most simple example here where that would have massive consequences is in how you would build a page.
At this moment you have a basepage, and X child pages which all have the basepage as resouceSuperType, inheriting everything from header to footer. Why would you ever want to break this ideal setup?
Greetings
Roy
> On 19 Mar 2016, at 11:41, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Maybe we should tackle this in steps. From what I heard so far, it seems
> we can agree on:
>
> a) forget about Resource#getResourceSuperType. This method is ignored
> from now on (and deprecated)
>
> How about having a dedicated service, like:
>
> d) we create a service which has three methods
>
> // get the super type
> String getResourceSuperType(ResourceResolver resolver, String
> resourceType);
>
> // get an ordered list of all super types
> List<String> getResourceSuperTypes(ResourceResolver resolver, String
> resourceType)
>
> // check if resourceType is checkResourceType (either directly or one
> of the parents
> boolean isResourceType(ResourceResolver resolver, String resourceType,
> String checkResourceType)
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: [RT] Improve resource type handling
Posted by Carsten Ziegeler <cz...@apache.org>.
Maybe we should tackle this in steps. From what I heard so far, it seems
we can agree on:
a) forget about Resource#getResourceSuperType. This method is ignored
from now on (and deprecated)
How about having a dedicated service, like:
d) we create a service which has three methods
// get the super type
String getResourceSuperType(ResourceResolver resolver, String
resourceType);
// get an ordered list of all super types
List<String> getResourceSuperTypes(ResourceResolver resolver, String
resourceType)
// check if resourceType is checkResourceType (either directly or one
of the parents
boolean isResourceType(ResourceResolver resolver, String resourceType,
String checkResourceType)
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org