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.
