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 <[email protected]> hat am 25. Januar 2013 um 20:26 geschrieben: > > On 25.01.2013, at 18:22, Ulrich Schmidt <[email protected]> > 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
