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.