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 <[EMAIL PROTECTED]> 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:
> > >
> > > <[EMAIL PROTECTED] 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.
> >
> >
>
>
