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