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
<[email protected]> 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 <[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
>

Reply via email to