Expand my Community achievements bar.

SOLVED

AEM Sling Model Re-usability

Avatar

Level 1

 

I have a unique requirement in project to re-use the custom sling model with multiple custom components.

 

I created, tested this thoroughly and everything working as expected but want to make sure anyone else tried this approach before with AEM. I know this is little out of way implementation for custom component general structure. This project has huge number of components and this pattern helps me to avoid creating hundreds of component specific duplicate sling models as the properties are mostly same with different HTMLs. I don't want to create as variants as they fall into different content groups for better authoring experience. Below is the scenario.

 

Sling Model:

standardContent.java with properties Title, Description, image, video, buttons

 

Component 1:

 
<div class="comp1" data-sly-use.model="com.project.core.models.standardContent">
// Component specific HTML based on DESIGN which is totally different behavior than comp 2 & 3
</div>

Component 2:

<div class="comp2" data-sly-use.model="com.project.core.models.standardContent">
// Component specific HTML based on DESIGN which is totally different behavior than comp 1 & 3
</div>

Component 3:

<div class="comp3" data-sly-use.model="com.project.core.models.standardContent">
// Component specific HTML based on DESIGN which is totally different behavior than comp 1 & 2
</div>

 

 

 

 

1 Accepted Solution

Avatar

Correct answer by
Level 10

HI @kvarthi ,

Using a single Sling Model for multiple custom components in AEM is a valid approach and can provide reusability and maintainability benefits. It allows you to define common properties and logic in one place and reuse them across different components.

In your scenario, you have a `standardContent` Sling Model with properties like `Title`, `Description`, `image`, `video`, and `buttons`. You then use this Sling Model in three different components (`comp1`, `comp2`, and `comp3`) to render component-specific HTML based on the design.

This approach can be beneficial in the following ways:

1. Reusability: By using a single Sling Model, you avoid duplicating code and logic across multiple components. Any changes or updates to the Sling Model will automatically reflect in all the components that use it.

2. Maintainability: Having a single Sling Model makes it easier to maintain and update the shared properties and logic. It reduces the effort required to make changes across multiple components.

3. Consistency: Using a common Sling Model ensures consistency in the properties and logic across different components. It helps in maintaining a unified structure and behavior throughout the project.

However, it's important to consider the following points:

1. Component-specific behavior: While reusing the Sling Model, make sure to handle component-specific behavior and rendering logic appropriately. You mentioned that the HTML for each component is different based on the design. Ensure that the Sling Model handles this variation correctly.

2. Naming conventions: Use meaningful and descriptive names for the Sling Model and its properties to avoid confusion and maintain clarity.

3. Testing and validation: Thoroughly test the Sling Model and its usage in different components to ensure that it functions as expected and meets the requirements of each component.

Overall, using a single Sling Model for multiple custom components can be a useful approach to achieve reusability and maintainability. It's always a good practice to thoroughly test and validate your implementation to ensure it meets your project's specific requirements.

View solution in original post

8 Replies

Avatar

Community Advisor

@kvarthi 

If the properties are getting saved to component node in all the components, then the html you provided for all 3 components will work. 

Avatar

Level 4

This is correct. to reuse same model across multiple components. This also promotes page performance as we leverage sling caching mechanism. 

Refer to this pattern in wcm core component. com.adobe.cq.wcm.core.components.models.Page model is called from multiple page components 

https://github.com/adobe/aem-core-wcm-components/blob/afb6ddaec90a9e13ca4b93f5e1eb5090682704d0/conte...

https://github.com/adobe/aem-core-wcm-components/blob/afb6ddaec90a9e13ca4b93f5e1eb5090682704d0/conte...

https://github.com/adobe/aem-core-wcm-components/blob/afb6ddaec90a9e13ca4b93f5e1eb5090682704d0/conte...

https://github.com/adobe/aem-core-wcm-components/blob/afb6ddaec90a9e13ca4b93f5e1eb5090682704d0/exten...

 

Another example, com.adobe.cq.wcm.core.components.models.Component is reused in list, embed, button, text etc

https://github.com/adobe/aem-core-wcm-components/blob/afb6ddaec90a9e13ca4b93f5e1eb5090682704d0/conte...

https://github.com/adobe/aem-core-wcm-components/blob/afb6ddaec90a9e13ca4b93f5e1eb5090682704d0/conte...

https://github.com/adobe/aem-core-wcm-components/blob/afb6ddaec90a9e13ca4b93f5e1eb5090682704d0/conte...

https://github.com/adobe/aem-core-wcm-components/blob/afb6ddaec90a9e13ca4b93f5e1eb5090682704d0/conte...

https://github.com/adobe/aem-core-wcm-components/blob/afb6ddaec90a9e13ca4b93f5e1eb5090682704d0/conte...

https://github.com/adobe/aem-core-wcm-components/blob/afb6ddaec90a9e13ca4b93f5e1eb5090682704d0/conte...

https://github.com/adobe/aem-core-wcm-components/blob/afb6ddaec90a9e13ca4b93f5e1eb5090682704d0/conte...

....

 

hope this gives you confidence to proceed with right design pattern DRY

 

 

 

Avatar

Level 1

Thanks for your confirmation and additional support links. Really helps.

Avatar

Correct answer by
Level 10

HI @kvarthi ,

Using a single Sling Model for multiple custom components in AEM is a valid approach and can provide reusability and maintainability benefits. It allows you to define common properties and logic in one place and reuse them across different components.

In your scenario, you have a `standardContent` Sling Model with properties like `Title`, `Description`, `image`, `video`, and `buttons`. You then use this Sling Model in three different components (`comp1`, `comp2`, and `comp3`) to render component-specific HTML based on the design.

This approach can be beneficial in the following ways:

1. Reusability: By using a single Sling Model, you avoid duplicating code and logic across multiple components. Any changes or updates to the Sling Model will automatically reflect in all the components that use it.

2. Maintainability: Having a single Sling Model makes it easier to maintain and update the shared properties and logic. It reduces the effort required to make changes across multiple components.

3. Consistency: Using a common Sling Model ensures consistency in the properties and logic across different components. It helps in maintaining a unified structure and behavior throughout the project.

However, it's important to consider the following points:

1. Component-specific behavior: While reusing the Sling Model, make sure to handle component-specific behavior and rendering logic appropriately. You mentioned that the HTML for each component is different based on the design. Ensure that the Sling Model handles this variation correctly.

2. Naming conventions: Use meaningful and descriptive names for the Sling Model and its properties to avoid confusion and maintain clarity.

3. Testing and validation: Thoroughly test the Sling Model and its usage in different components to ensure that it functions as expected and meets the requirements of each component.

Overall, using a single Sling Model for multiple custom components can be a useful approach to achieve reusability and maintainability. It's always a good practice to thoroughly test and validate your implementation to ensure it meets your project's specific requirements.

Avatar

Level 1

Thanks for the confirmation. You highlighted the key pointers in detailed and its really helpful.

Avatar

Level 2

Hi @kvarthi ,

Though whatever you have done is correct but there can be another approach which might be better depends on yours use case.

You may provide a drop downs of all the variant in dialog if most of the fields are same. Based on the variant you can render html with the help of sightly.

Even if few fields are different you can use container and show hide fields in dialog based on variant.

If fields are same definitely you should go with drop down approach. 

Avatar

Community Advisor

In a scalable solution if I were to do this, I would rather create an super class sling model (parent class). This super class would have all the common methods that you would be using in your sub classes. Each sub class would inherit from the parent class, and so when you create 3 components, each component will have a unique name, but the backend sling model would be commonly used. This pattern will allow efficiency (by re-using common methods) and extendability, so if you have a unique requirement on one of those 3 component's you can easily do so.