You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Ulrich Schmidt <Ul...@gombers.de> on 2013/01/25 18:22:55 UTC
Resource Resolving basic questions
Being new with Sling, I need to get familiar with it. Until now I understand
that there is no comprehensive reference describing the Sling architecture and
methods in detail. Until now I saw some CQ5-samples which don't work for me and
I don't understand how one comes to expect that they should work.
So I'm looking for a document, source, ruleset or anything else where I can
extract the way how resolving is done. I found the Interface "ResourceResolver"
supplied by Sling but have no clue which class is implementing it. Maybe such a
class would help. I'm astonished anyway, why this interface is mentioned in all
the websites I found until now instead of the implementing class. As if it was
users responsibilty to do the resolving.
This is what I understand so far (source: Sling
cheatsheet(http://dev.day.com/content/ddc/blog/2008/07/cheatsheet.html) and CQ
Basics (http://dev.day.com/docs/en/cq/current/developing/the_basics.html):
(1) Sling splts the URI in different parts and maps them to the resources.
(2) The path is either mapped according to the sling:resourceType or the
sling:resourceSuperType (both attributes either specified to the path-node or
inherited from parents) or to the node (specified by the path) itself; in this
case the node must be of type nt:file or contain a subnode of type nt:file.
(3) In either case (resolved by sling:resourceType, sling:resourceSuperType or
using the node itself) Sling looks for scripts contained in the resolved node.
(4) There are four ScriptTypes supported: est (ECMAScript), java (Java Source
becomes compiled), jsp (Java Server Pages) and jst (Java Script Templates). The
type "js" is not mentioned in "The Basics".
(5) For HTTP-GET requests there is a best match sequence for looking up the
script name; for HTTP-PUT-requests an exact-match is required.
Is this ok so far?
These are some of the samples I don't understand:
see also "How to Create a Fully Featured Internet Website"
(http://dev.day.com/docs/en/cq/current/howto/website.html) and the discussion at
the bottom. Ulrich, thats me.
(a) the node /content/mywebsite/en/products is of type cq:Page and the subnode
jcr:content has an attribute
sling:resourceType=mywebsite/components/contentpage.
The path /apps/mywebsite/components/contentpage contains a node body.jsp (and
some others referenced by body.jsp).
The request http://localhost:4502//content/mywebsite/en/products.html renders
the node /apps/mywebsite/components/contentpage/body.jsp.
This is the first thing I don't understand. Why is body.jsp looked up for
rendering; why does it belong to the best match sequence showed in (5).
(b) One of the jsps included by body.jsp displays an image. The image is also a
node in /apps/mywebsite/components/contentpage/
Within the jsp the string /content/mywebsite/en/products/navimage.png is
specified. But the image does not show up in the browser. When I specify
/apps/mywebsite/components/contentpage/navimage.png instead all works fine. So
if resolving for the website
http://localhost:4502//content/mywebsite/en/products.html works, why doesn't it
work for the image.
(c) In the screencast "TheServerSide,com in 15 minutes
(http://dev.day.com/content/ddc/blog/2008/04/firststeps2.html)" a static html is
converted to dynamic. They create a node /apps/tss/posts/html.jst and invoke it
with "localhost:4502/content/tss/posts/*.post.html". (As this screencast was
recorded in 2008 they recommend to change the node to /apps/tss/post.jst, but no
recommendation for the HTTP-Request). The node /content/tss isn't there when the
URL is invoked first; the post.jst POST-request creates it.
So there cannot be a sling:requestTyppe anywhere - how can we expect that Sling
will correctly map the HTTP-request generated by typing the URL.
As resource resolving is very basic for developing on CQ5, I urgently need to
understand the logic here, Any help is appreciated.
Ulrich
Re: Resource Resolving basic questions
Posted by "David G." <da...@gmail.com>.
This isn't a criticism, as I doubt i could write better documentation :)
But something I noted when i first got started w Sling was the
documentation on the site seems to pre-suppose a general understanding
of Sling and supporting tech (JCR, OSGi, etc). It feels more like a
reference for folks that already understand Sling, its principles,
hooks, conventions, etc. rather than a guide to "getting started".
Maybe a good way to put it is the docs site "assumes context" which
more junior folks, by their very nature, simply don't have.
On Mon, Jan 28, 2013 at 5:32 AM, Ulrich Schmidt
<Ul...@gombers.de> wrote:
> Thank you for your comments. they were very valuable – I learned a lot by
> working with them.
>
> I've added my remarks within the text below.
>
> Ulrich
>
>
> Alexander Klimetschek <ak...@adobe.com> hat am 25. Januar 2013 um 20:26
> geschrieben:
>>
>> On 25.01.2013, at 18:22, Ulrich Schmidt <Ul...@gombers.de>
>> wrote:
>>
>> > Being new with Sling, I need to get familiar with it. Until now I understand
>> > that there is no comprehensive reference describing the Sling architecture
>> > and
>> > methods in detail. Until now I saw some CQ5-samples which don't work for me
>> > and
>> > I don't understand how one comes to expect that they should work.
>>
>> There's also
>>
>> http://sling.apache.org/site/architecture.html
>> http://sling.apache.org/site/dispatching-requests.html
>> http://sling.apache.org/site/url-decomposition.html
>>
>> and other links on http://sling.apache.org/site/the-sling-engine.html that
>> might help.
>>
>> And the wiki https://cwiki.apache.org/SLING/index.html has some useful stuff
>> as well.
>>
>
>
>
> I saw those pages already. The sites itself don't tell much, I probably have to
> follow the hyperlinks and read it all. It feels like searching the needle in the
> haystack. As this is the the main purpose of Sling - relsoving resources - I
> would have expected that there is a basic description of it. To get a complete
> picture of this very basic stuff I have to combine all of the pages I read until
> now and some more which I missed to read yet. I'm not used to this approach
> having the architectural description of a single function distributed over so
> much documents. But anyway - thank you for the hints. I will work on this and
> maybe ask some other questions in a separate thread.
>
>
>> > This is what I understand so far (source: Sling
>> > cheatsheet(http://dev.day.com/content/ddc/blog/2008/07/cheatsheet.html) and
>> > CQ
>> > Basics (http://dev.day.com/docs/en/cq/current/developing/the_basics.html):
>> >
>> > (1) Sling splts the URI in different parts and maps them to the resources.
>>
>> Yes.
>>
>> > (2) The path is either mapped according to the sling:resourceType or the
>> > sling:resourceSuperType (both attributes either specified to the path-node
>> > or
>> > inherited from parents) or to the node (specified by the path) itself; in
>> > this
>> > case the node must be of type nt:file or contain a subnode of type nt:file.
>>
>> Not really. After parsing the URL, the longest matching resource found is used
>> as resource for the request. First step done.
>
>
>
> Isn't that what I explained above exactly that what Lars Trieloff explained in
> his "Sling cheatsheet" at number 3 "Get Resource Type"?. I don't understand,
> what longest match means here. The cheatsheet explains an exact sequence here -
> first sling:resourceType then sling:resourceSuperType and at last nt:file
>
>
>
> To follow the cheatsheet-example: There is an absolute path "/wiki/Sling" within
> the JCR. This node contains a rt=wiki/page
>
>
>
>
>
>
>>
>> Then for rendering, sling searches for a servlet/script. This is done based on
>> the sling:resourceType & sling:resourceSuperType, or, if not available, the
>> node type of the request resource is used (for JCR resources; some:NodeType =>
>> read like a resource type some/NodeType).
>
>>
>
>
>
> 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). If the
> node is of type "nt:file" we are done.
>
> If it contains a rt or rst-attribute this will be used to retrieve script
> location.
>
>
>> > (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?
>
>
>> > (4) There are four ScriptTypes supported: est (ECMAScript), java (Java
>> > Source
>> > becomes compiled), jsp (Java Server Pages) and jst (Java Script Templates).
>> > The
>> > type "js" is not mentioned in "The Basics".
>>
>> esP, not esT. esp are javascript templates (ecmascript = javascript), i.e.
>> like JSPs.
>>
>
> Typing error, sorry.
>
>
>> Example:
>> https://cwiki.apache.org/SLING/scripting-variables.html#Scriptingvariables-ESP
>>
>> Any JSR 223 Java scripting engine can be hooked in. There are scala and groovy
>> floating around for example. See also
>> http://stackoverflow.com/questions/6558055/is-osgi-fundamentally-incompatible-with-jsr-223-scripting-language-discovery/6562563#6562563
>>
>> > (5) For HTTP-GET requests there is a best match sequence for looking up the
>> > script name; for HTTP-PUT-requests an exact-match is required.
>>
>> The normal variant for a GET request to a html extension would be "html.jsp"
>> (assuming jsps). Since this is very common, as a dev you are likely to have
>> many html.jsp files open, not knowing where they belong, Sling added a
>> shortcut to use the component name (parent folder) instead:
>>
>> /apps/projects/components/foo/foo.jsp
>>
>> > These are some of the samples I don't understand:
>> >
>> > see also "How to Create a Fully Featured Internet Website"
>> > (http://dev.day.com/docs/en/cq/current/howto/website.html) and the
>> > discussion at
>> > the bottom. Ulrich, thats me.
>>
>> I guess that's more of a question for the CQ forum or mailing list, but I'll
>> answer inline anyway:
>>
>> > (a) the node /content/mywebsite/en/products is of type cq:Page and the
>> > subnode
>> > jcr:content has an attribute
>> > sling:resourceType=mywebsite/components/contentpage.
>> > The path /apps/mywebsite/components/contentpage contains a node body.jsp
>> > (and
>> > some others referenced by body.jsp).
>> > The request http://localhost:4502//content/mywebsite/en/products.html
>> > renders
>> > the node /apps/mywebsite/components/contentpage/body.jsp.
>> > This is the first thing I don't understand. Why is body.jsp looked up for
>> > rendering; why does it belong to the best match sequence showed in (5).
>>
>> There is more (also noted on the page, but no so clear): there is a
>> contentpage.jsp which is called first (that's the GET-html shortcut jsp). This
>> one then explicitly includes head.jsp & body.jsp, using the CQ-specific
>> <cq:include> tag (which includes the script directly, working differently than
>> sling:include).
>>
>
> Sorry – you are right. The question occurred to me when I typed this on my IPad
> and had no access to my system. I could have seen this by myself.
>
>
>> > (b) One of the jsps included by body.jsp displays an image. The image is
>> > also a
>> > node in /apps/mywebsite/components/contentpage/
>> > Within the jsp the string /content/mywebsite/en/products/navimage.png is
>> > specified. But the image does not show up in the browser. When I specify
>> > /apps/mywebsite/components/contentpage/navimage.png instead all works fine.
>> > So
>> > if resolving for the website
>> > http://localhost:4502//content/mywebsite/en/products.html works, why doesn't
>> > it
>> > work for the image.
>>
>> Maybe the /apps/mywebsite/components/contentpage/navimage.png.java is missing?
>> Or the navimage.png fails because some content is missing...
>>
>> Tip: go to http://localhost:4502/system/console/requests to get a list of the
>> recent requests and their request progress log, which shows you resource
>> resolution, script resolution and inclusions.
>
>
>
> The node /apps/mywebsite/components/contentpage/navimage.png.java is there. But
> now I've got some logs, thank you. I can't see anything special within those
> logs – but I will check with adobe for the error.
>
>
>>
>> > (c) In the screencast "TheServerSide,com in 15 minutes
>> > (http://dev.day.com/content/ddc/blog/2008/04/firststeps2.html)" a static
>> > html is
>> > converted to dynamic. They create a node /apps/tss/posts/html.jst and invoke
>> > it
>> > with "localhost:4502/content/tss/posts/*.post.html". (As this screencast was
>> > recorded in 2008 they recommend to change the node to /apps/tss/post.jst,
>> > but no
>> > recommendation for the HTTP-Request). The node /content/tss isn't there when
>> > the
>> > URL is invoked first; the post.jst POST-request creates it.
>> > So there cannot be a sling:requestTyppe anywhere - how can we expect that
>> > Sling
>> > will correctly map the HTTP-request generated by typing the URL.
>>
>> I think in this sample the (optional) path based resource type provider [0] is
>> active. This makes /content/corporate/jobs/developer.html look up scripts
>> under in/apps/content/corporate/jobs/ (if the there is no node or no
>> sling:resourceType at /content/corporate/jobs/developer).
>>
>> Note that this is not very common and I'd suggest to always use content-based
>> resolution as that gives you more transparency, ACLs and full control over the
>> resolution (i.e. if something goes wrong, you change the content, no need to
>> find the "magic" code and make it more complex through exceptions etc.).
>>
>> [0] https://svn.apache.org/repos/asf/sling/trunk/samples/path-based-rtp/
>>
>> HTH,
>> Alex
>
Re: Resource Resolving basic questions
Posted by Julian Sedding <js...@gmail.com>.
Hello Ulrich
Just a small thing I spotted:
If you request the URI /content/mywebsite/en/products/navimage.png,
the script at /apps/mywebsite/components/contentpage/navimage.png.java
will not help you. It might help you, if you were requesting
/content/mywebsite/en/products.navimage.png (note that I changed the
last slash into a dot, thus triggering the script that responds to the
selector "navimage").
If this doesn't work (or if you want to learn more), try requesting
/content/mywebsite/en/products/jcr:content.navimage.png and look at
what's really happening in the previous two requests via
http://localhost:4502/system/console/requests (a very helpful tool, as
Alex suggested). This will point you to the scripts in
/libs/foundation/components/primary/cq/Page, which do some CQ-specific
handling of cq:Page nodes.
Hope this helps and you will soon start enjoying your Sling-experience more.
Regards
Julian
On Mon, Jan 28, 2013 at 11:32 AM, Ulrich Schmidt
<Ul...@gombers.de> wrote:
> Thank you for your comments. they were very valuable – I learned a lot by
> working with them.
>
> I've added my remarks within the text below.
>
> Ulrich
>
>
> Alexander Klimetschek <ak...@adobe.com> hat am 25. Januar 2013 um 20:26
> geschrieben:
>>
>> On 25.01.2013, at 18:22, Ulrich Schmidt <Ul...@gombers.de>
>> wrote:
>>
>> > Being new with Sling, I need to get familiar with it. Until now I understand
>> > that there is no comprehensive reference describing the Sling architecture
>> > and
>> > methods in detail. Until now I saw some CQ5-samples which don't work for me
>> > and
>> > I don't understand how one comes to expect that they should work.
>>
>> There's also
>>
>> http://sling.apache.org/site/architecture.html
>> http://sling.apache.org/site/dispatching-requests.html
>> http://sling.apache.org/site/url-decomposition.html
>>
>> and other links on http://sling.apache.org/site/the-sling-engine.html that
>> might help.
>>
>> And the wiki https://cwiki.apache.org/SLING/index.html has some useful stuff
>> as well.
>>
>
>
>
> I saw those pages already. The sites itself don't tell much, I probably have to
> follow the hyperlinks and read it all. It feels like searching the needle in the
> haystack. As this is the the main purpose of Sling - relsoving resources - I
> would have expected that there is a basic description of it. To get a complete
> picture of this very basic stuff I have to combine all of the pages I read until
> now and some more which I missed to read yet. I'm not used to this approach
> having the architectural description of a single function distributed over so
> much documents. But anyway - thank you for the hints. I will work on this and
> maybe ask some other questions in a separate thread.
>
>
>> > This is what I understand so far (source: Sling
>> > cheatsheet(http://dev.day.com/content/ddc/blog/2008/07/cheatsheet.html) and
>> > CQ
>> > Basics (http://dev.day.com/docs/en/cq/current/developing/the_basics.html):
>> >
>> > (1) Sling splts the URI in different parts and maps them to the resources.
>>
>> Yes.
>>
>> > (2) The path is either mapped according to the sling:resourceType or the
>> > sling:resourceSuperType (both attributes either specified to the path-node
>> > or
>> > inherited from parents) or to the node (specified by the path) itself; in
>> > this
>> > case the node must be of type nt:file or contain a subnode of type nt:file.
>>
>> Not really. After parsing the URL, the longest matching resource found is used
>> as resource for the request. First step done.
>
>
>
> Isn't that what I explained above exactly that what Lars Trieloff explained in
> his "Sling cheatsheet" at number 3 "Get Resource Type"?. I don't understand,
> what longest match means here. The cheatsheet explains an exact sequence here -
> first sling:resourceType then sling:resourceSuperType and at last nt:file
>
>
>
> To follow the cheatsheet-example: There is an absolute path "/wiki/Sling" within
> the JCR. This node contains a rt=wiki/page
>
>
>
>
>
>
>>
>> Then for rendering, sling searches for a servlet/script. This is done based on
>> the sling:resourceType & sling:resourceSuperType, or, if not available, the
>> node type of the request resource is used (for JCR resources; some:NodeType =>
>> read like a resource type some/NodeType).
>
>>
>
>
>
> 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). If the
> node is of type "nt:file" we are done.
>
> If it contains a rt or rst-attribute this will be used to retrieve script
> location.
>
>
>> > (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?
>
>
>> > (4) There are four ScriptTypes supported: est (ECMAScript), java (Java
>> > Source
>> > becomes compiled), jsp (Java Server Pages) and jst (Java Script Templates).
>> > The
>> > type "js" is not mentioned in "The Basics".
>>
>> esP, not esT. esp are javascript templates (ecmascript = javascript), i.e.
>> like JSPs.
>>
>
> Typing error, sorry.
>
>
>> Example:
>> https://cwiki.apache.org/SLING/scripting-variables.html#Scriptingvariables-ESP
>>
>> Any JSR 223 Java scripting engine can be hooked in. There are scala and groovy
>> floating around for example. See also
>> http://stackoverflow.com/questions/6558055/is-osgi-fundamentally-incompatible-with-jsr-223-scripting-language-discovery/6562563#6562563
>>
>> > (5) For HTTP-GET requests there is a best match sequence for looking up the
>> > script name; for HTTP-PUT-requests an exact-match is required.
>>
>> The normal variant for a GET request to a html extension would be "html.jsp"
>> (assuming jsps). Since this is very common, as a dev you are likely to have
>> many html.jsp files open, not knowing where they belong, Sling added a
>> shortcut to use the component name (parent folder) instead:
>>
>> /apps/projects/components/foo/foo.jsp
>>
>> > These are some of the samples I don't understand:
>> >
>> > see also "How to Create a Fully Featured Internet Website"
>> > (http://dev.day.com/docs/en/cq/current/howto/website.html) and the
>> > discussion at
>> > the bottom. Ulrich, thats me.
>>
>> I guess that's more of a question for the CQ forum or mailing list, but I'll
>> answer inline anyway:
>>
>> > (a) the node /content/mywebsite/en/products is of type cq:Page and the
>> > subnode
>> > jcr:content has an attribute
>> > sling:resourceType=mywebsite/components/contentpage.
>> > The path /apps/mywebsite/components/contentpage contains a node body.jsp
>> > (and
>> > some others referenced by body.jsp).
>> > The request http://localhost:4502//content/mywebsite/en/products.html
>> > renders
>> > the node /apps/mywebsite/components/contentpage/body.jsp.
>> > This is the first thing I don't understand. Why is body.jsp looked up for
>> > rendering; why does it belong to the best match sequence showed in (5).
>>
>> There is more (also noted on the page, but no so clear): there is a
>> contentpage.jsp which is called first (that's the GET-html shortcut jsp). This
>> one then explicitly includes head.jsp & body.jsp, using the CQ-specific
>> <cq:include> tag (which includes the script directly, working differently than
>> sling:include).
>>
>
> Sorry – you are right. The question occurred to me when I typed this on my IPad
> and had no access to my system. I could have seen this by myself.
>
>
>> > (b) One of the jsps included by body.jsp displays an image. The image is
>> > also a
>> > node in /apps/mywebsite/components/contentpage/
>> > Within the jsp the string /content/mywebsite/en/products/navimage.png is
>> > specified. But the image does not show up in the browser. When I specify
>> > /apps/mywebsite/components/contentpage/navimage.png instead all works fine.
>> > So
>> > if resolving for the website
>> > http://localhost:4502//content/mywebsite/en/products.html works, why doesn't
>> > it
>> > work for the image.
>>
>> Maybe the /apps/mywebsite/components/contentpage/navimage.png.java is missing?
>> Or the navimage.png fails because some content is missing...
>>
>> Tip: go to http://localhost:4502/system/console/requests to get a list of the
>> recent requests and their request progress log, which shows you resource
>> resolution, script resolution and inclusions.
>
>
>
> The node /apps/mywebsite/components/contentpage/navimage.png.java is there. But
> now I've got some logs, thank you. I can't see anything special within those
> logs – but I will check with adobe for the error.
>
>
>>
>> > (c) In the screencast "TheServerSide,com in 15 minutes
>> > (http://dev.day.com/content/ddc/blog/2008/04/firststeps2.html)" a static
>> > html is
>> > converted to dynamic. They create a node /apps/tss/posts/html.jst and invoke
>> > it
>> > with "localhost:4502/content/tss/posts/*.post.html". (As this screencast was
>> > recorded in 2008 they recommend to change the node to /apps/tss/post.jst,
>> > but no
>> > recommendation for the HTTP-Request). The node /content/tss isn't there when
>> > the
>> > URL is invoked first; the post.jst POST-request creates it.
>> > So there cannot be a sling:requestTyppe anywhere - how can we expect that
>> > Sling
>> > will correctly map the HTTP-request generated by typing the URL.
>>
>> I think in this sample the (optional) path based resource type provider [0] is
>> active. This makes /content/corporate/jobs/developer.html look up scripts
>> under in/apps/content/corporate/jobs/ (if the there is no node or no
>> sling:resourceType at /content/corporate/jobs/developer).
>>
>> Note that this is not very common and I'd suggest to always use content-based
>> resolution as that gives you more transparency, ACLs and full control over the
>> resolution (i.e. if something goes wrong, you change the content, no need to
>> find the "magic" code and make it more complex through exceptions etc.).
>>
>> [0] https://svn.apache.org/repos/asf/sling/trunk/samples/path-based-rtp/
>>
>> HTH,
>> Alex
>
Re: Resource Resolving basic questions
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 28.01.2013, at 11:32, Ulrich Schmidt <Ul...@gombers.de> 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
Re: Resource Resolving basic questions
Posted by Ulrich Schmidt <Ul...@gombers.de>.
Thank you for your comments. they were very valuable – I learned a lot by
working with them.
I've added my remarks within the text below.
Ulrich
Alexander Klimetschek <ak...@adobe.com> hat am 25. Januar 2013 um 20:26
geschrieben:
>
> On 25.01.2013, at 18:22, Ulrich Schmidt <Ul...@gombers.de>
> wrote:
>
> > Being new with Sling, I need to get familiar with it. Until now I understand
> > that there is no comprehensive reference describing the Sling architecture
> > and
> > methods in detail. Until now I saw some CQ5-samples which don't work for me
> > and
> > I don't understand how one comes to expect that they should work.
>
> There's also
>
> http://sling.apache.org/site/architecture.html
> http://sling.apache.org/site/dispatching-requests.html
> http://sling.apache.org/site/url-decomposition.html
>
> and other links on http://sling.apache.org/site/the-sling-engine.html that
> might help.
>
> And the wiki https://cwiki.apache.org/SLING/index.html has some useful stuff
> as well.
>
I saw those pages already. The sites itself don't tell much, I probably have to
follow the hyperlinks and read it all. It feels like searching the needle in the
haystack. As this is the the main purpose of Sling - relsoving resources - I
would have expected that there is a basic description of it. To get a complete
picture of this very basic stuff I have to combine all of the pages I read until
now and some more which I missed to read yet. I'm not used to this approach
having the architectural description of a single function distributed over so
much documents. But anyway - thank you for the hints. I will work on this and
maybe ask some other questions in a separate thread.
> > This is what I understand so far (source: Sling
> > cheatsheet(http://dev.day.com/content/ddc/blog/2008/07/cheatsheet.html) and
> > CQ
> > Basics (http://dev.day.com/docs/en/cq/current/developing/the_basics.html):
> >
> > (1) Sling splts the URI in different parts and maps them to the resources.
>
> Yes.
>
> > (2) The path is either mapped according to the sling:resourceType or the
> > sling:resourceSuperType (both attributes either specified to the path-node
> > or
> > inherited from parents) or to the node (specified by the path) itself; in
> > this
> > case the node must be of type nt:file or contain a subnode of type nt:file.
>
> Not really. After parsing the URL, the longest matching resource found is used
> as resource for the request. First step done.
Isn't that what I explained above exactly that what Lars Trieloff explained in
his "Sling cheatsheet" at number 3 "Get Resource Type"?. I don't understand,
what longest match means here. The cheatsheet explains an exact sequence here -
first sling:resourceType then sling:resourceSuperType and at last nt:file
To follow the cheatsheet-example: There is an absolute path "/wiki/Sling" within
the JCR. This node contains a rt=wiki/page
>
> Then for rendering, sling searches for a servlet/script. This is done based on
> the sling:resourceType & sling:resourceSuperType, or, if not available, the
> node type of the request resource is used (for JCR resources; some:NodeType =>
> read like a resource type some/NodeType).
>
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). If the
node is of type "nt:file" we are done.
If it contains a rt or rst-attribute this will be used to retrieve script
location.
> > (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?
> > (4) There are four ScriptTypes supported: est (ECMAScript), java (Java
> > Source
> > becomes compiled), jsp (Java Server Pages) and jst (Java Script Templates).
> > The
> > type "js" is not mentioned in "The Basics".
>
> esP, not esT. esp are javascript templates (ecmascript = javascript), i.e.
> like JSPs.
>
Typing error, sorry.
> Example:
> https://cwiki.apache.org/SLING/scripting-variables.html#Scriptingvariables-ESP
>
> Any JSR 223 Java scripting engine can be hooked in. There are scala and groovy
> floating around for example. See also
> http://stackoverflow.com/questions/6558055/is-osgi-fundamentally-incompatible-with-jsr-223-scripting-language-discovery/6562563#6562563
>
> > (5) For HTTP-GET requests there is a best match sequence for looking up the
> > script name; for HTTP-PUT-requests an exact-match is required.
>
> The normal variant for a GET request to a html extension would be "html.jsp"
> (assuming jsps). Since this is very common, as a dev you are likely to have
> many html.jsp files open, not knowing where they belong, Sling added a
> shortcut to use the component name (parent folder) instead:
>
> /apps/projects/components/foo/foo.jsp
>
> > These are some of the samples I don't understand:
> >
> > see also "How to Create a Fully Featured Internet Website"
> > (http://dev.day.com/docs/en/cq/current/howto/website.html) and the
> > discussion at
> > the bottom. Ulrich, thats me.
>
> I guess that's more of a question for the CQ forum or mailing list, but I'll
> answer inline anyway:
>
> > (a) the node /content/mywebsite/en/products is of type cq:Page and the
> > subnode
> > jcr:content has an attribute
> > sling:resourceType=mywebsite/components/contentpage.
> > The path /apps/mywebsite/components/contentpage contains a node body.jsp
> > (and
> > some others referenced by body.jsp).
> > The request http://localhost:4502//content/mywebsite/en/products.html
> > renders
> > the node /apps/mywebsite/components/contentpage/body.jsp.
> > This is the first thing I don't understand. Why is body.jsp looked up for
> > rendering; why does it belong to the best match sequence showed in (5).
>
> There is more (also noted on the page, but no so clear): there is a
> contentpage.jsp which is called first (that's the GET-html shortcut jsp). This
> one then explicitly includes head.jsp & body.jsp, using the CQ-specific
> <cq:include> tag (which includes the script directly, working differently than
> sling:include).
>
Sorry – you are right. The question occurred to me when I typed this on my IPad
and had no access to my system. I could have seen this by myself.
> > (b) One of the jsps included by body.jsp displays an image. The image is
> > also a
> > node in /apps/mywebsite/components/contentpage/
> > Within the jsp the string /content/mywebsite/en/products/navimage.png is
> > specified. But the image does not show up in the browser. When I specify
> > /apps/mywebsite/components/contentpage/navimage.png instead all works fine.
> > So
> > if resolving for the website
> > http://localhost:4502//content/mywebsite/en/products.html works, why doesn't
> > it
> > work for the image.
>
> Maybe the /apps/mywebsite/components/contentpage/navimage.png.java is missing?
> Or the navimage.png fails because some content is missing...
>
> Tip: go to http://localhost:4502/system/console/requests to get a list of the
> recent requests and their request progress log, which shows you resource
> resolution, script resolution and inclusions.
The node /apps/mywebsite/components/contentpage/navimage.png.java is there. But
now I've got some logs, thank you. I can't see anything special within those
logs – but I will check with adobe for the error.
>
> > (c) In the screencast "TheServerSide,com in 15 minutes
> > (http://dev.day.com/content/ddc/blog/2008/04/firststeps2.html)" a static
> > html is
> > converted to dynamic. They create a node /apps/tss/posts/html.jst and invoke
> > it
> > with "localhost:4502/content/tss/posts/*.post.html". (As this screencast was
> > recorded in 2008 they recommend to change the node to /apps/tss/post.jst,
> > but no
> > recommendation for the HTTP-Request). The node /content/tss isn't there when
> > the
> > URL is invoked first; the post.jst POST-request creates it.
> > So there cannot be a sling:requestTyppe anywhere - how can we expect that
> > Sling
> > will correctly map the HTTP-request generated by typing the URL.
>
> I think in this sample the (optional) path based resource type provider [0] is
> active. This makes /content/corporate/jobs/developer.html look up scripts
> under in/apps/content/corporate/jobs/ (if the there is no node or no
> sling:resourceType at /content/corporate/jobs/developer).
>
> Note that this is not very common and I'd suggest to always use content-based
> resolution as that gives you more transparency, ACLs and full control over the
> resolution (i.e. if something goes wrong, you change the content, no need to
> find the "magic" code and make it more complex through exceptions etc.).
>
> [0] https://svn.apache.org/repos/asf/sling/trunk/samples/path-based-rtp/
>
> HTH,
> Alex
Re: Resource Resolving basic questions
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 25.01.2013, at 18:22, Ulrich Schmidt <Ul...@gombers.de> wrote:
> Being new with Sling, I need to get familiar with it. Until now I understand
> that there is no comprehensive reference describing the Sling architecture and
> methods in detail. Until now I saw some CQ5-samples which don't work for me and
> I don't understand how one comes to expect that they should work.
There's also
http://sling.apache.org/site/architecture.html
http://sling.apache.org/site/dispatching-requests.html
http://sling.apache.org/site/url-decomposition.html
and other links on http://sling.apache.org/site/the-sling-engine.html that might help.
And the wiki https://cwiki.apache.org/SLING/index.html has some useful stuff as well.
> This is what I understand so far (source: Sling
> cheatsheet(http://dev.day.com/content/ddc/blog/2008/07/cheatsheet.html) and CQ
> Basics (http://dev.day.com/docs/en/cq/current/developing/the_basics.html):
>
> (1) Sling splts the URI in different parts and maps them to the resources.
Yes.
> (2) The path is either mapped according to the sling:resourceType or the
> sling:resourceSuperType (both attributes either specified to the path-node or
> inherited from parents) or to the node (specified by the path) itself; in this
> case the node must be of type nt:file or contain a subnode of type nt:file.
Not really. After parsing the URL, the longest matching resource found is used as resource for the request. First step done.
Then for rendering, sling searches for a servlet/script. This is done based on the sling:resourceType & sling:resourceSuperType, or, if not available, the node type of the request resource is used (for JCR resources; some:NodeType => read like a resource type some/NodeType).
> (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)
> (4) There are four ScriptTypes supported: est (ECMAScript), java (Java Source
> becomes compiled), jsp (Java Server Pages) and jst (Java Script Templates). The
> type "js" is not mentioned in "The Basics".
esP, not esT. esp are javascript templates (ecmascript = javascript), i.e. like JSPs.
Example: https://cwiki.apache.org/SLING/scripting-variables.html#Scriptingvariables-ESP
Any JSR 223 Java scripting engine can be hooked in. There are scala and groovy floating around for example. See also
http://stackoverflow.com/questions/6558055/is-osgi-fundamentally-incompatible-with-jsr-223-scripting-language-discovery/6562563#6562563
> (5) For HTTP-GET requests there is a best match sequence for looking up the
> script name; for HTTP-PUT-requests an exact-match is required.
The normal variant for a GET request to a html extension would be "html.jsp" (assuming jsps). Since this is very common, as a dev you are likely to have many html.jsp files open, not knowing where they belong, Sling added a shortcut to use the component name (parent folder) instead:
/apps/projects/components/foo/foo.jsp
> These are some of the samples I don't understand:
>
> see also "How to Create a Fully Featured Internet Website"
> (http://dev.day.com/docs/en/cq/current/howto/website.html) and the discussion at
> the bottom. Ulrich, thats me.
I guess that's more of a question for the CQ forum or mailing list, but I'll answer inline anyway:
> (a) the node /content/mywebsite/en/products is of type cq:Page and the subnode
> jcr:content has an attribute
> sling:resourceType=mywebsite/components/contentpage.
> The path /apps/mywebsite/components/contentpage contains a node body.jsp (and
> some others referenced by body.jsp).
> The request http://localhost:4502//content/mywebsite/en/products.html renders
> the node /apps/mywebsite/components/contentpage/body.jsp.
> This is the first thing I don't understand. Why is body.jsp looked up for
> rendering; why does it belong to the best match sequence showed in (5).
There is more (also noted on the page, but no so clear): there is a contentpage.jsp which is called first (that's the GET-html shortcut jsp). This one then explicitly includes head.jsp & body.jsp, using the CQ-specific <cq:include> tag (which includes the script directly, working differently than sling:include).
> (b) One of the jsps included by body.jsp displays an image. The image is also a
> node in /apps/mywebsite/components/contentpage/
> Within the jsp the string /content/mywebsite/en/products/navimage.png is
> specified. But the image does not show up in the browser. When I specify
> /apps/mywebsite/components/contentpage/navimage.png instead all works fine. So
> if resolving for the website
> http://localhost:4502//content/mywebsite/en/products.html works, why doesn't it
> work for the image.
Maybe the /apps/mywebsite/components/contentpage/navimage.png.java is missing? Or the navimage.png fails because some content is missing...
Tip: go to http://localhost:4502/system/console/requests to get a list of the recent requests and their request progress log, which shows you resource resolution, script resolution and inclusions.
> (c) In the screencast "TheServerSide,com in 15 minutes
> (http://dev.day.com/content/ddc/blog/2008/04/firststeps2.html)" a static html is
> converted to dynamic. They create a node /apps/tss/posts/html.jst and invoke it
> with "localhost:4502/content/tss/posts/*.post.html". (As this screencast was
> recorded in 2008 they recommend to change the node to /apps/tss/post.jst, but no
> recommendation for the HTTP-Request). The node /content/tss isn't there when the
> URL is invoked first; the post.jst POST-request creates it.
> So there cannot be a sling:requestTyppe anywhere - how can we expect that Sling
> will correctly map the HTTP-request generated by typing the URL.
I think in this sample the (optional) path based resource type provider [0] is active. This makes /content/corporate/jobs/developer.html look up scripts under in/apps/content/corporate/jobs/ (if the there is no node or no sling:resourceType at /content/corporate/jobs/developer).
Note that this is not very common and I'd suggest to always use content-based resolution as that gives you more transparency, ACLs and full control over the resolution (i.e. if something goes wrong, you change the content, no need to find the "magic" code and make it more complex through exceptions etc.).
[0] https://svn.apache.org/repos/asf/sling/trunk/samples/path-based-rtp/
HTH,
Alex