Expand my Community achievements bar.

Learn about Edge Delivery Services in upcoming GEM session
SOLVED

What defines what nodes and properties makeup a component, with jcr:primaryType=cq:Component?

Avatar

Level 2

For example, if I look at /libs/foundation/components/parsys there is a child node parsys.jsp. Does any jsp file get executed? Or what declares that that jsp file should be executed?

I have similar questions about cq:Template, cq:Page etc.

Note that the question is not: "how do I create a component?"

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

@kendalls5216292 Disclaimer :- ✌ I am not a SLING expert . But still I would like to point out few things I know . As much as I know. 

Lets take your question one by one 

 

if I look at /libs/foundation/components/parsys there is a child node parsys.jsp.

        Does any jsp file get executed? - Yes , it does. Much before the entire stack was changed to HTL, we were that old guys with a lot of JSPs. So a lot of components in the /libs/foundation/components still uses JSPs for rendering . Why ? for backward compatibility (I think that's the right word ). There might be a lot of legacy projects still running on them , or quite a few projects in which they might not have completely migrated ut still using some of these components. So yes , these JSPs execute. 

 

Or what declares that that jsp file should be executed? - To exactly answer that one , you have to go through the sling resolution . A better start would be https://issues.apache.org/jira/browse/SLING-387 here. It exactly defines how sling resolves a component. So when you hit a content node in the browser , lets say /content/we-retail/en/us/home.html , the first thing which sling looks for to execute and deliver your content is a property called sling:resourceType under your home node. This resourceType in 90% scenarios will be pointing to a cq:Component in your repository. Now as for any rendering logic, Sling also need to define a rendering logic for its components. And that what its main Job is to. So, as per its definition and sling resolution principles , the JSP gets executed in the order it should be. 

 

May be a little reading on SLING might help https://sling.apache.org/documentation.html also Script-resolution https://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html 

 

A similar kind of explanation can be found here -

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/template-component-can-t-o...

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/sling-resource-resolution-...

 

Updated :- https://issues.apache.org/jira/browse/SLING-278 this was the ticket for sling resolution and inheritance. I have updated the correct ticket details for sling resolution

 

Hope this helps and gives little bit of idea. 

Thanks

Veena

 

View solution in original post

3 Replies

Avatar

Correct answer by
Community Advisor

@kendalls5216292 Disclaimer :- ✌ I am not a SLING expert . But still I would like to point out few things I know . As much as I know. 

Lets take your question one by one 

 

if I look at /libs/foundation/components/parsys there is a child node parsys.jsp.

        Does any jsp file get executed? - Yes , it does. Much before the entire stack was changed to HTL, we were that old guys with a lot of JSPs. So a lot of components in the /libs/foundation/components still uses JSPs for rendering . Why ? for backward compatibility (I think that's the right word ). There might be a lot of legacy projects still running on them , or quite a few projects in which they might not have completely migrated ut still using some of these components. So yes , these JSPs execute. 

 

Or what declares that that jsp file should be executed? - To exactly answer that one , you have to go through the sling resolution . A better start would be https://issues.apache.org/jira/browse/SLING-387 here. It exactly defines how sling resolves a component. So when you hit a content node in the browser , lets say /content/we-retail/en/us/home.html , the first thing which sling looks for to execute and deliver your content is a property called sling:resourceType under your home node. This resourceType in 90% scenarios will be pointing to a cq:Component in your repository. Now as for any rendering logic, Sling also need to define a rendering logic for its components. And that what its main Job is to. So, as per its definition and sling resolution principles , the JSP gets executed in the order it should be. 

 

May be a little reading on SLING might help https://sling.apache.org/documentation.html also Script-resolution https://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html 

 

A similar kind of explanation can be found here -

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/template-component-can-t-o...

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/sling-resource-resolution-...

 

Updated :- https://issues.apache.org/jira/browse/SLING-278 this was the ticket for sling resolution and inheritance. I have updated the correct ticket details for sling resolution

 

Hope this helps and gives little bit of idea. 

Thanks

Veena

 

Avatar

Level 10

Hi @kendalls5216292,

You asked about properties of node types and about execution of JSPs. This leaves me a bit confused because the two things are not really related  I think @VeenaVikraman gave you a good answer about JSPs and sling resolution, here is my answer about node type properties.

cq:Component

Description
Defines a CQ component.
  • @prop jcr:title - Title for the component.
  • @prop jcr:description - Description of the component.
  • @node dialog - Primary dialog.
  • @prop dialogPath - Primary dialog path (alternative to dialog).
  • @node design_dialog - Design dialog.
  • @prop cq:cellName - Name of the design cell.
  • @prop cq:isContainer - Indicates whether this is a container component. This forces the cell names of child components to be used instead of path names. For example, the parsys is a container component. If this value is not defined, the check is made based on the existence of a cq:childEditConfig .
  • @prop cq:noDecoration - If true, no decoration div tags are drawn when including this component.
  • @node cq:editConfig - The configuration that defines the parameters for the edit bar.
  • @node cq:childEditConfig - The edit configuration that is inherited by child components.
  • @node cq:htmlTag - Defines additional tag attributes that are added to the "surrounding" div tag when the component is included.
  • @node icon.png - A file that holds a characteristic icon.
  • @node thumbnail.png - A file that holds a characteristic thumbnail image.
  • @prop allowedParents - Regular expression patterns to determine the path(s) of components that are allowed as parent components.
  • @prop allowedChildren - Regular expression patterns to determine the path(s) of components that are allowed as child components.
  • @node virtual - Contains subnodes that reflect virtual components used for the component drag and drop.
  • @prop componentGroup - Name of the component group, used for the component drag and drop.
  • @node cq:infoProviders - Contains subnodes, each of which has a property className that refers to a PageInfoProvider .

 That is from this page, which lists the OOTB node properties used in AEM (many of which come from CQ5, AEM predecessor). Hope this helps!