You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Tobias Bocanegra <to...@day.com> on 2008/02/06 02:16:18 UTC

resource type inheritance

hi,
i think we need some sort of resource type inheritance. the use case
is the following:

assume we have:
  /apps/base/html.jsp
  /apps/base/title/png.jsp
  /content/en/sling:resourceType = "/apps/base"

where the image script produces some title image. which is used:
  <img src="/content/en.title.png"/>

now, i define a 'sub type' which has a different body than the base
but uses the same image script:
  /apps/special/html.jsp
  /content/special/sling:resourceType = "/apps/special"

now the img:
  <img src="/content/special.title.png"/>

this wont work of course, since it does not define the title script.
the workaround is to add a /apps/special/title/png.jsp which
jsp-includes the base one, eg:

<%@include file="/apps/base/title.png.jsp" %>

but this is not usable at all.

what i suggest is to introduce a "sling:parentType" which you place to
the folder of the script, eg:

/apps/special/sling:parentType="/apps/base"

and the script resolution would check if the resource type node
defines such a property and uses it as new resource type for the
resolution.

WDYT ?
regards, toby

btw: this is not only a problem just for 'image scripts' but also for
all resources that are included via an url and not via the path /
resource type.
-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Re: resource type inheritance

Posted by Tobias Bocanegra <to...@day.com>.
thanks. i'll take a look at it today :-)
regards, toby

On 2/27/08, Felix Meschberger <fm...@gmail.com> wrote:
> This functionality is now implemented as of Rev. 631604.
>
>  Have fun !
>
>  Regards
>  Felix
>
>  Am Donnerstag, den 07.02.2008, 09:17 +0100 schrieb Tobias Bocanegra:
>
> > sounds good!
>  >
>  > On 2/7/08, Felix Meschberger <fm...@gmail.com> wrote:
>  > > Hi all,
>  > >
>  > > I think this idea is certainly worth considering, though of course with
>  > > a slightly more general approach:
>  > >
>  > > (1) Extend the Resource API to include a method
>  > >
>  > >         String getSuperResourceType() - returns the resource super type
>  > > or null if there
>  > >                 is none
>  > >
>  > > (2) JCR Resource Implementation 1: The JCR implementation of the
>  > > Resource interface based on nodes (JcrNodeResource) will return the
>  > > value of the sling:superResourceType field if such a field is defined.
>  > > The implementation based on properties (JcrPropertyResource) will return
>  > > the value of the sling:superResourceType property of the parent node
>  > > plus the property name, similar as the resource type of the property
>  > > resource is defined.
>  > >
>  > > (3) JCR Resource Implementation 2: If the sling:superResourceType field
>  > > does not exist, the super types of the primary node type may be
>  > > considered: If the primary node type as one or more base types, select
>  > > any of the non-mixin base types as the sling:superResourceType. Most of
>  > > the time, a primary node type will only have a single non-mixin base
>  > > type and multiple mixin base types. So this mechanism should be pretty
>  > > stable. In cases where this might not be the case, the primary node type
>  > > may still be defined with a sling:superResourceType property with a
>  > > predefined (auto created default value) value.
>  > >
>  > > (4) Other Resource Implementations: May or may not support super
>  > > resource types, currently, neither bundle nor the servlet based resource
>  > > implementations will probably support this.
>  > >
>  > > (5) Servlet/Script resolution: The resolver will primarily consider the
>  > > resource type. If no script could be found, the resource's super
>  > > resource type (if defined) is considered. If not script can be found, an
>  > > algorithm as follows may be applied:
>  > >
>  > >                  String type = resource.getSuperResourceType();
>  > >                  type = JcrResourceUtil.getTypeAsPath(type);
>  > >                  Resource typeResource =
>  > > resourceResolver.getResource(type);
>  > >                  type = typeResource.getSuperResourceType();
>  > >                  while (type != null) {
>  > >                      servlet = getServletForType(request, type);
>  > >                      if (servelt != null) {
>  > >                          ... done ...
>  > >                      }
>  > >                      type = JcrResourceUtil.getTypeAsPath(type);
>  > >                      Resource typeResource =
>  > > resourceResolver.getResource(type);
>  > >                      type = typeResource.getSuperResourceType();
>  > >                  }
>  > >
>  > >
>  > > WDYT ?
>  > >
>  > > Regards
>  > > Felix
>  > >
>  > > Am Mittwoch, den 06.02.2008, 02:16 +0100 schrieb Tobias Bocanegra:
>  > > > hi,
>  > > > i think we need some sort of resource type inheritance. the use case
>  > > > is the following:
>  > > >
>  > > > assume we have:
>  > > >   /apps/base/html.jsp
>  > > >   /apps/base/title/png.jsp
>  > > >   /content/en/sling:resourceType = "/apps/base"
>  > > >
>  > > > where the image script produces some title image. which is used:
>  > > >   <img src="/content/en.title.png"/>
>  > > >
>  > > > now, i define a 'sub type' which has a different body than the base
>  > > > but uses the same image script:
>  > > >   /apps/special/html.jsp
>  > > >   /content/special/sling:resourceType = "/apps/special"
>  > > >
>  > > > now the img:
>  > > >   <img src="/content/special.title.png"/>
>  > > >
>  > > > this wont work of course, since it does not define the title script.
>  > > > the workaround is to add a /apps/special/title/png.jsp which
>  > > > jsp-includes the base one, eg:
>  > > >
>  > > > <%@include file="/apps/base/title.png.jsp" %>
>  > > >
>  > > > but this is not usable at all.
>  > > >
>  > > > what i suggest is to introduce a "sling:parentType" which you place to
>  > > > the folder of the script, eg:
>  > > >
>  > > > /apps/special/sling:parentType="/apps/base"
>  > > >
>  > > > and the script resolution would check if the resource type node
>  > > > defines such a property and uses it as new resource type for the
>  > > > resolution.
>  > > >
>  > > > WDYT ?
>  > > > regards, toby
>  > > >
>  > > > btw: this is not only a problem just for 'image scripts' but also for
>  > > > all resources that are included via an url and not via the path /
>  > > > resource type.
>  > >
>  > >
>  >
>  >
>
>


-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Re: resource type inheritance

Posted by Felix Meschberger <fm...@gmail.com>.
This functionality is now implemented as of Rev. 631604.

Have fun ! 

Regards
Felix

Am Donnerstag, den 07.02.2008, 09:17 +0100 schrieb Tobias Bocanegra:
> sounds good!
> 
> On 2/7/08, Felix Meschberger <fm...@gmail.com> wrote:
> > Hi all,
> >
> > I think this idea is certainly worth considering, though of course with
> > a slightly more general approach:
> >
> > (1) Extend the Resource API to include a method
> >
> >         String getSuperResourceType() - returns the resource super type
> > or null if there
> >                 is none
> >
> > (2) JCR Resource Implementation 1: The JCR implementation of the
> > Resource interface based on nodes (JcrNodeResource) will return the
> > value of the sling:superResourceType field if such a field is defined.
> > The implementation based on properties (JcrPropertyResource) will return
> > the value of the sling:superResourceType property of the parent node
> > plus the property name, similar as the resource type of the property
> > resource is defined.
> >
> > (3) JCR Resource Implementation 2: If the sling:superResourceType field
> > does not exist, the super types of the primary node type may be
> > considered: If the primary node type as one or more base types, select
> > any of the non-mixin base types as the sling:superResourceType. Most of
> > the time, a primary node type will only have a single non-mixin base
> > type and multiple mixin base types. So this mechanism should be pretty
> > stable. In cases where this might not be the case, the primary node type
> > may still be defined with a sling:superResourceType property with a
> > predefined (auto created default value) value.
> >
> > (4) Other Resource Implementations: May or may not support super
> > resource types, currently, neither bundle nor the servlet based resource
> > implementations will probably support this.
> >
> > (5) Servlet/Script resolution: The resolver will primarily consider the
> > resource type. If no script could be found, the resource's super
> > resource type (if defined) is considered. If not script can be found, an
> > algorithm as follows may be applied:
> >
> >                  String type = resource.getSuperResourceType();
> >                  type = JcrResourceUtil.getTypeAsPath(type);
> >                  Resource typeResource =
> > resourceResolver.getResource(type);
> >                  type = typeResource.getSuperResourceType();
> >                  while (type != null) {
> >                      servlet = getServletForType(request, type);
> >                      if (servelt != null) {
> >                          ... done ...
> >                      }
> >                      type = JcrResourceUtil.getTypeAsPath(type);
> >                      Resource typeResource =
> > resourceResolver.getResource(type);
> >                      type = typeResource.getSuperResourceType();
> >                  }
> >
> >
> > WDYT ?
> >
> > Regards
> > Felix
> >
> > Am Mittwoch, den 06.02.2008, 02:16 +0100 schrieb Tobias Bocanegra:
> > > hi,
> > > i think we need some sort of resource type inheritance. the use case
> > > is the following:
> > >
> > > assume we have:
> > >   /apps/base/html.jsp
> > >   /apps/base/title/png.jsp
> > >   /content/en/sling:resourceType = "/apps/base"
> > >
> > > where the image script produces some title image. which is used:
> > >   <img src="/content/en.title.png"/>
> > >
> > > now, i define a 'sub type' which has a different body than the base
> > > but uses the same image script:
> > >   /apps/special/html.jsp
> > >   /content/special/sling:resourceType = "/apps/special"
> > >
> > > now the img:
> > >   <img src="/content/special.title.png"/>
> > >
> > > this wont work of course, since it does not define the title script.
> > > the workaround is to add a /apps/special/title/png.jsp which
> > > jsp-includes the base one, eg:
> > >
> > > <%@include file="/apps/base/title.png.jsp" %>
> > >
> > > but this is not usable at all.
> > >
> > > what i suggest is to introduce a "sling:parentType" which you place to
> > > the folder of the script, eg:
> > >
> > > /apps/special/sling:parentType="/apps/base"
> > >
> > > and the script resolution would check if the resource type node
> > > defines such a property and uses it as new resource type for the
> > > resolution.
> > >
> > > WDYT ?
> > > regards, toby
> > >
> > > btw: this is not only a problem just for 'image scripts' but also for
> > > all resources that are included via an url and not via the path /
> > > resource type.
> >
> >
> 
> 


Re: resource type inheritance

Posted by Tobias Bocanegra <to...@day.com>.
sounds good!

On 2/7/08, Felix Meschberger <fm...@gmail.com> wrote:
> Hi all,
>
> I think this idea is certainly worth considering, though of course with
> a slightly more general approach:
>
> (1) Extend the Resource API to include a method
>
>         String getSuperResourceType() - returns the resource super type
> or null if there
>                 is none
>
> (2) JCR Resource Implementation 1: The JCR implementation of the
> Resource interface based on nodes (JcrNodeResource) will return the
> value of the sling:superResourceType field if such a field is defined.
> The implementation based on properties (JcrPropertyResource) will return
> the value of the sling:superResourceType property of the parent node
> plus the property name, similar as the resource type of the property
> resource is defined.
>
> (3) JCR Resource Implementation 2: If the sling:superResourceType field
> does not exist, the super types of the primary node type may be
> considered: If the primary node type as one or more base types, select
> any of the non-mixin base types as the sling:superResourceType. Most of
> the time, a primary node type will only have a single non-mixin base
> type and multiple mixin base types. So this mechanism should be pretty
> stable. In cases where this might not be the case, the primary node type
> may still be defined with a sling:superResourceType property with a
> predefined (auto created default value) value.
>
> (4) Other Resource Implementations: May or may not support super
> resource types, currently, neither bundle nor the servlet based resource
> implementations will probably support this.
>
> (5) Servlet/Script resolution: The resolver will primarily consider the
> resource type. If no script could be found, the resource's super
> resource type (if defined) is considered. If not script can be found, an
> algorithm as follows may be applied:
>
>                  String type = resource.getSuperResourceType();
>                  type = JcrResourceUtil.getTypeAsPath(type);
>                  Resource typeResource =
> resourceResolver.getResource(type);
>                  type = typeResource.getSuperResourceType();
>                  while (type != null) {
>                      servlet = getServletForType(request, type);
>                      if (servelt != null) {
>                          ... done ...
>                      }
>                      type = JcrResourceUtil.getTypeAsPath(type);
>                      Resource typeResource =
> resourceResolver.getResource(type);
>                      type = typeResource.getSuperResourceType();
>                  }
>
>
> WDYT ?
>
> Regards
> Felix
>
> Am Mittwoch, den 06.02.2008, 02:16 +0100 schrieb Tobias Bocanegra:
> > hi,
> > i think we need some sort of resource type inheritance. the use case
> > is the following:
> >
> > assume we have:
> >   /apps/base/html.jsp
> >   /apps/base/title/png.jsp
> >   /content/en/sling:resourceType = "/apps/base"
> >
> > where the image script produces some title image. which is used:
> >   <img src="/content/en.title.png"/>
> >
> > now, i define a 'sub type' which has a different body than the base
> > but uses the same image script:
> >   /apps/special/html.jsp
> >   /content/special/sling:resourceType = "/apps/special"
> >
> > now the img:
> >   <img src="/content/special.title.png"/>
> >
> > this wont work of course, since it does not define the title script.
> > the workaround is to add a /apps/special/title/png.jsp which
> > jsp-includes the base one, eg:
> >
> > <%@include file="/apps/base/title.png.jsp" %>
> >
> > but this is not usable at all.
> >
> > what i suggest is to introduce a "sling:parentType" which you place to
> > the folder of the script, eg:
> >
> > /apps/special/sling:parentType="/apps/base"
> >
> > and the script resolution would check if the resource type node
> > defines such a property and uses it as new resource type for the
> > resolution.
> >
> > WDYT ?
> > regards, toby
> >
> > btw: this is not only a problem just for 'image scripts' but also for
> > all resources that are included via an url and not via the path /
> > resource type.
>
>


-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Re: resource type inheritance

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Feb 7, 2008 8:42 AM, Felix Meschberger <fm...@gmail.com> wrote:

> WDYT ?

It all sounds good to me, except that I'd call the property

  sling:resourceSupertype

instead of

  sling:superResourceType

and talk of "resource supertype" instead of "super resource type",
that sounds clearer to me as supertypes and subtypes are known
concepts.

-Bertrand

Re: resource type inheritance

Posted by Felix Meschberger <fm...@gmail.com>.
Hi all,

I think this idea is certainly worth considering, though of course with
a slightly more general approach:

(1) Extend the Resource API to include a method

        String getSuperResourceType() - returns the resource super type
or null if there
                is none

(2) JCR Resource Implementation 1: The JCR implementation of the
Resource interface based on nodes (JcrNodeResource) will return the
value of the sling:superResourceType field if such a field is defined.
The implementation based on properties (JcrPropertyResource) will return
the value of the sling:superResourceType property of the parent node
plus the property name, similar as the resource type of the property
resource is defined.

(3) JCR Resource Implementation 2: If the sling:superResourceType field
does not exist, the super types of the primary node type may be
considered: If the primary node type as one or more base types, select
any of the non-mixin base types as the sling:superResourceType. Most of
the time, a primary node type will only have a single non-mixin base
type and multiple mixin base types. So this mechanism should be pretty
stable. In cases where this might not be the case, the primary node type
may still be defined with a sling:superResourceType property with a
predefined (auto created default value) value.

(4) Other Resource Implementations: May or may not support super
resource types, currently, neither bundle nor the servlet based resource
implementations will probably support this.

(5) Servlet/Script resolution: The resolver will primarily consider the
resource type. If no script could be found, the resource's super
resource type (if defined) is considered. If not script can be found, an
algorithm as follows may be applied:

                 String type = resource.getSuperResourceType();
                 type = JcrResourceUtil.getTypeAsPath(type);
                 Resource typeResource =
resourceResolver.getResource(type);
                 type = typeResource.getSuperResourceType();
                 while (type != null) {
                     servlet = getServletForType(request, type);
                     if (servelt != null) {
                         ... done ...
                     }
                     type = JcrResourceUtil.getTypeAsPath(type);
                     Resource typeResource =
resourceResolver.getResource(type);
                     type = typeResource.getSuperResourceType();
                 }


WDYT ?

Regards
Felix

Am Mittwoch, den 06.02.2008, 02:16 +0100 schrieb Tobias Bocanegra:
> hi,
> i think we need some sort of resource type inheritance. the use case
> is the following:
> 
> assume we have:
>   /apps/base/html.jsp
>   /apps/base/title/png.jsp
>   /content/en/sling:resourceType = "/apps/base"
> 
> where the image script produces some title image. which is used:
>   <img src="/content/en.title.png"/>
> 
> now, i define a 'sub type' which has a different body than the base
> but uses the same image script:
>   /apps/special/html.jsp
>   /content/special/sling:resourceType = "/apps/special"
> 
> now the img:
>   <img src="/content/special.title.png"/>
> 
> this wont work of course, since it does not define the title script.
> the workaround is to add a /apps/special/title/png.jsp which
> jsp-includes the base one, eg:
> 
> <%@include file="/apps/base/title.png.jsp" %>
> 
> but this is not usable at all.
> 
> what i suggest is to introduce a "sling:parentType" which you place to
> the folder of the script, eg:
> 
> /apps/special/sling:parentType="/apps/base"
> 
> and the script resolution would check if the resource type node
> defines such a property and uses it as new resource type for the
> resolution.
> 
> WDYT ?
> regards, toby
> 
> btw: this is not only a problem just for 'image scripts' but also for
> all resources that are included via an url and not via the path /
> resource type.