Expand my Community achievements bar.

SOLVED

extract other child component's properties in current child component among the list of child nodes on AEM Page using Sightly alone (no sightly model in java)

Avatar

Level 1
extract other child component's properties in current child component among the list of child nodes on AEM Page using Sightly alone (no sightly model in java)
For example, the aem page named test is created with the header, hero and footer components.
From the footer's HTL, there is a need to find the header component present in the list of child nodes of AEM Page named 'test' and if header component is present, then extract the properties of header component.
psrpjayaem_0-1599146761433.png

 

1 Accepted Solution

Avatar

Correct answer by
Level 10

Hi @psrpjayaem,

As @arunpatidar mentioned, there is no easy way to do this in HTL and it will always be more verbose and less performance (due to lots of iterating) to perform this kind of complex logic than if you used a Sling model.

In my opinion, you really should be using a model for this kind of requirement, for a number or reasons:

  1. You can unit test this logic if it's in a model, but not if it's in HTL
  2. If you wish to re-use the logic elsewhere, then ou can do so using Java but not using HTL
  3. You can't do any complex error handling in HTL (what if there is no footer node? What if the node is there but it doesn't contain the property you're looking for? Etc.)
  4. Using Java will be far more performant since you can use lookups for properties rather than iterating through all of them and doing a string comparison based on the name each time.
  5. You also de-couple the logic from the view. This is standard best practice in all frameworks I know of, so future developers will have an easier time reading your code.

Hope that helps 

View solution in original post

6 Replies

Avatar

Community Advisor

Hi @psrpjayaem 

 

With HTL, you can extract first the parent of the current component that is footer. Then you can extract header resource from parent resource like this:

 

<div data-sly-test.headerResource="${resource.parent.header}">
<!-- Extract properties if header resource exists with ${headerResource.properties.property1}-->
</div>


OR-----------------------------------------

<div data-sly-list="${resource.parent.listChildren}">
    <div data-sly-test.headerResource="${item.name == 'header'}">
        <!-- Extract properties if header resource exists with ${headerResource.properties.property1}-->
    </div>
</div>

 

 

Here resource represents the current resource. resource.parent basically call getParent method of resource api and provide you with parent resource.

 

you can both the options and whatever fits your usecase better, you can try.

 

Hope it Helps!

Thanks

Avatar

Level 1
Thanks for the prompt help. I followed this to some extent. However resource is not pointing to footer when printed. Instead resource is printing the template used on the page. In my particular, with reference to screenshot above, I have to traverse from current-node (footer) to the parent node (i.e. /content/) and then drill down to the sibling node i.e.(header) and extract relevant properties.

Avatar

Community Advisor

Is there any specific reason why you should not use models ?

Avatar

Level 1
only presentation logic in front-ned need be applied based on the components present on the aem page instance created

Avatar

Community Advisor

You can access the resources using HTL Global Object, but you cannot perform any Business operation in HTL like getting a specific child node without iterating. You need to use either JS Use API or Java.



Arun Patidar

Avatar

Correct answer by
Level 10

Hi @psrpjayaem,

As @arunpatidar mentioned, there is no easy way to do this in HTL and it will always be more verbose and less performance (due to lots of iterating) to perform this kind of complex logic than if you used a Sling model.

In my opinion, you really should be using a model for this kind of requirement, for a number or reasons:

  1. You can unit test this logic if it's in a model, but not if it's in HTL
  2. If you wish to re-use the logic elsewhere, then ou can do so using Java but not using HTL
  3. You can't do any complex error handling in HTL (what if there is no footer node? What if the node is there but it doesn't contain the property you're looking for? Etc.)
  4. Using Java will be far more performant since you can use lookups for properties rather than iterating through all of them and doing a string comparison based on the name each time.
  5. You also de-couple the logic from the view. This is standard best practice in all frameworks I know of, so future developers will have an easier time reading your code.

Hope that helps