AEM page rendering sequence

[au4liferz]

Can someone detail the sequence that AEM uses to render pages? For instance, if there are multiple components on the page, how does AEM decide which component to render first? Is there any way to control the order in which components are rendered? I'd imagine that the template is processed first, then the header, footer, content, and other page components in a typical page hierarchy, then the components are rendered next??? Is this correct? If not, please lay out the sequence step by step and/or point me to the appropriate documentation, (though I've not seen this documented in the AEM documentation). I'm primarily interested in doing this for AEM 6.1, but if there is a significant difference for 5.6.1, please call out the differences.

[smacdonald2008]

AEM renders based on Sling principles. See "Sling Request Processing" located here:

https://docs.adobe.com/docs/en/aem/6-1/develop/the-basics.html

everything on a page is a resource that is rendered by sling. 

[au4liferz]

I've seen the documentation that you listed, but I don't believe it addresses the questions that I asked, (e.g. regarding the order in which components are rendered etc.). If I have dependencies between components, and want to ensure that component A is executed and rendered, before component B's logic is executed, how can I do this? Can anyone detail the sequence of exactly how the template, various page components, and ultimately, the UI components are executed/rendered?

[smacdonald2008]

The order in which components (which are resources in SLing) are rendered are governed by Sling. There is a lot of on-line Sling documentation that explains this. (the AEM docs references sling docs - this is why you will not find this theory information in AEM docs). 

http://dev.day.com/content/ddc/blog/2010/08/understanding_howsc.html

http://sling.apache.org/site/component-api.html

http://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html

[smacdonald2008]

Also - i have never ever heard of anyone having issues with the way sling renders components and dependencies. The biggest thing to remember is to make sure that when you reference components in CQ -- for example using cq:include (see below) - make sure you provide a valid JCR location. 

The <cq:include> tag includes a resource into the current page.

It has the following attributes:

flush

A boolean defining whether to flush the output before including the target.
path

The path to the resource object to be included in the current request processing. If this path is relative it is appended to the path of the current resource whose script is including the given resource. Either path and resourceType, or script must be specified.

[leeasling]

I agree with Sam on this too, but since the answer doesn't seem to satisfy you, i'll try to explain it a little different.

A page is rendered by node order.  The jcr:content node contains the reference to the page component and template, and is rendered as such.  Next, each node structure below jcr:content is rendered.  Let's say you have:

jcr:content
    par (foundation/components/parsys)
        title (foundation/components/title)
        text (foundation/components/text)

it will be output on the page as ordered, paragraph system > title component > text

I don't really understand why you would have a components logic be based on another component that may or may not exist on the page, to me that sounds like it needs to be re-worked, but i don't know the use case.

[Lokesh_Shivalingaiah]

At the end of it, any page is a HTML. It renders in the similar order of your HTML divs. So firstly global.jsp, then head.jsp etc...

All the components would be stored in content.jsp and the order would be order in which nodes are stored under jcr:content

Hope thats clear.

[au4liferz]

Thanks so much to all of you for the answers. I'm being asked to do some things that stretch the tool to the limits of its ability, while at the same time trying to learn the platform, and technologies. The contributions on this board have been invaluable.

[Jörg_Hoh]

bsloki wrote...

At the end of it, any page is a HTML. It renders in the similar order of your HTML divs. So firstly global.jsp, then head.jsp etc...

All the components would be stored in content.jsp and the order would be order in which nodes are stored under jcr:content

Hope thats clear.

This isn't really the case. The rendering of a page is determined by the page component. The code (expressed either in Sightly or in JSP taglib markup) then determines in which order the components on the page are rendered. The order of the components below the page/jcr:content/ node is completely irrelevant (with the most obvious exception being the parsys, where the element order matters), so that the footer is printed at the bottom of the page is just a matter of this code.

Jörg

[au4liferz]

Jorg,

How does the page component determine the rendering order? Is it simply based on the order in which you include the various page sub-components, (e.g. header.jsp, headlibs.jsp, body, content, footer etc.)??? What determines the order of the various custom components included in each parsys? If I have two or three parsys's on a page, and each has one of more custom components, how is the rendering order determined??? If you can go into detail, and/or refer me to documentation, please do so.

[Jörg_Hoh · Accepted solution]

Hi,

yes, that's correct. The order in which the components of the page are included (in the page component) determines the order in which their output appear in the HTML. If you have 3 parsys components on the page, these parsys components are included in the very same way as other components. I would advise to start with documentation available on docs.adobe.com [1][2] and start from there. When you have AEM running, you should also start analyzing and playing with the geometrixx application (/content/geometrixx/en).

kind regards,
Jörg

[1] https://docs.adobe.com/docs/en/aem/6-1/develop/the-basics.html
[2] https://docs.adobe.com/docs/en/aem/6-1/develop/components.html