Resource Type Overwrite

Status: DRAFT
Created: 18. February 2008
Author: fmeschbe
JIRA: –
References: http://www.mail-archive.com/sling-dev@incubator.apache.org/msg02592.html

Introduction

Currently the type of a Resource based on a JCR node is derived either from the sling:resourceType property or from the primary node type. For a a JCR property based Resource the type is derived from the sling:resourceType property or primary node type of the parent node plus the name of the property. For other Resources the type is set through domain specific ways.

In his mail Jukka Zitting proposes the introduction of a sling:config node somewhere along the parent path of a Resource to overwrite the type of any Resource. In this concept I elaborate on this proposal and present a possible implementation.

I didn't propose to overwrite the type. My proposal was to overwrite the type -> component mapping for a subtree. The resource type is IMHO an inherent property of the resource and should not be "changed" by configuration. - Jukka

The sling:resourceTypeOverwrite Resource

Before the Resource resolver returns a Resource, it looks along the parent path for any child resource whose name is derived from the original type of the Resource:

String type = null;
String relPath = "sling:resourceTypeOverwrite/" + encodeType(resource.getResourceType());
Resource test = resource;
while (!isRootResource(test) && type == null) {
  Resource overWrite = getResource(test, relPath);
  if (overWrite != null) {
    // if overWrite is a Property based Resource
    String overWriteType = overWrite.adaptTo(String.class);
    if (overWriteType != null) {
       type = overWriteType;
    } else {
       // otherwise use the resource as the absolute resource type
       type = overWrite.getPath();
    }
  }
}

The idea is to find a Resource named after the original Reource, which may be used as the type overwrite. If a resource is found, which adapts to a String, the String is used as the overwriting resource type. Otherwise, the Resource found is assumed to contain one or more scripts to be used to render the Resource.

Some examples might illustrate this. First we setup a simple Resource hierarchy:

    /
    +-- parent
          +-- child1
                +-- primaryNodeType = nt:file
          +-- child2
                +-- sling:resourceType = some/type
          +-- child3
                +-- sling:resourceType = a/type
          +-- sling:resourceTypeOverwrite
                +-- nt:file = some/other/type
                +-- some%2ftype
                     +-- html.jsp

In this example, requesting /parent/child1 returns a Resource with type some/other/type because the sling:resourceTypeOverwrite/nt:file Resource is a property resource adapting to the String value some/other/type.

Requesting /parent/child2 returns a Resource whose type is set to /parent/sling:resourceTypeOverwrite/some%2ftype because the sling:resourceTypeOverwrite/some%2ftype Reosurce is a node Resource not adapting to a String value.

Finally, requesting /parent/child3 returns a Resource whose type is a/type because there is no Resource type overwrite.

The sling:ResourceType Mixin Node Type

To help in the creation of Resource type overwrites and attaching to any existing node a new mixin node type is defined:

[sling:ResourceType]
  mix
+ sling:resourceTypeOverwrite (nt:unstructured)

Resource Type Encoding

In the example code presented above, the original resource type is indicated to be encoded. The reason for this encoding is, that a resource type may be a path, which should be used as the name of a property or child node. To be able to do that, the original resource type is encoded as follows:

  • If the resource type contains just a single colon and not slashes, the type is taken as is. The main use for this is to support primary node types such as nt:file as resource types and not requiring encoding.
  • Otherwise the resource type is URL encoded.
  • No labels