Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn more

View all

Sign in to view all badges

SOLVED

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

kendalls5216292
Level 2
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
Veena_Vikram
Correct answer by
Community Advisor
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
Veena_Vikram
Correct answer by
Community Advisor
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

Theo_Pendle
Community Advisor
Community Advisor

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 @Veena_Vikram 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! 🙂