On 28.01.2013, at 11:32, Ulrich Schmidt <[email protected]>
wrote:
> I see that I have mixed up path resolution and resource resolution
> (retrieving rendering script). But what does "longest matching resource"
> mean. To use the cheatsheet-sample: The absolute path /wiki/Sling must exist
> to resolve the request (or it is mapped by some means. then the mapped path
> must exist).
Longest matching: If there would be just a node /wiki (and no /wiki/Sling), a
request with an URL such as /wiki/Sling.html would still match:
An example, given the URL /wiki/Sling.html
/wiki/Sling exists
=> resource "/wiki/Sling"
extension "html"
/wiki exists (but no Sling below)
=> resource "/wiki"
suffix "/Sling.html"
nothing matching exists
=> resource type = sling:nonexisting
path = /wiki/Sling.html (the full unmodified url)
> If the node is of type "nt:file" we are done.
No, for resource resolution, the node type is completely irrelevant. Any JCR
node will be seen as a resource.
> If it contains a rt or rst-attribute this will be used to retrieve script
> location.
Yes. If these properties do not exist, the node type will be used. E.g.
"nt:file" would become rt = "nt/file". Or if the special path resource type
provider is installed (or any other), it would use the path if no rt/rst
properties are present.
(Note that these are "properties" in JCR, not "attributes").
> > > (3) In either case (resolved by sling:resourceType,
> > > sling:resourceSuperType or
> > > using the node itself) Sling looks for scripts contained in the resolved
> > > node.
> >
> > If you mean resolve node = request resource, then no. The resource type is
> > looked up
> > - by path (if it's absolute): rt = /apps/project/components/foo
> > - inside the resource resolver search path (if it's relative, common)
> > rt = project/components/foo => search in /apps/project/components/foo and
> > in /libs/project/components/foo (if search path is /apps, /libs)
> >
>
> Sorry, I'm not sure whether I understand what is compared in expression
> "resolve node == request.resource". The script location is looked up as
> described above and the script itself selected according to a best match
> rule. Looking up inside the resource resolver search path probably means
> probably the same as what I called "using best match rule", doesn't it?
Not really... I see the confusion. Both steps (resource resolution + script
resolution) use the same ResourceResolver service [1], which is very central to
Sling, but quite differently:
a) resource resolution uses ResourceResolver.resolve()
- using the request resource resolver = under the name of the user of the
request (important for ACLs)
- if there is no match, it will return the special NonExistingResource (rt =
sling:nonexisting as mentioned above)
- no search path is used here
b) script resolution used ResourceResolver.getResource()
- using a special resource resolver instance with a special "script" user (has
rights to read .jsp etc.; basically the execute permission if you will)
- if there is no match, returns null
- applies the search path if you path a relative path (e.g. a resource type
such as "project/components/foo")
Note that case b) is very common for any server-side processing where you want
to look up resources. It's like Session.getNode() in the JCR API.
[1]
http://sling.apache.org/apidocs/sling6/org/apache/sling/api/resource/ResourceResolver.html
Cheers,
Alex
