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. > 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
