Hi @IshaJa ,
In Adobe Experience Manager (AEM), Sightly (HTL) is designed to keep the markup and logic cleanly separated. Variables set within a data-sly-template scope are generally intended to be used only within that template. However, if you need to expose a variable from within a template to the outer context where the template is called, there are a few approaches you can consider.
Approach 1: Using Data-Sly-Resource
One common approach is to leverage data-sly-resource to include a component that can use the model and expose its properties. This way, you can encapsulate the logic inside the component and reuse it without adding Java dependencies to multiple repositories.
Approach 2: Passing Values Back via Template Parameters
Another approach involves passing values back from the template by using additional parameters. This way, you can define a parameter that the caller can use to receive the computed value.
Example of Approach 2
Here's a detailed example:
Define the Template
In your template file (e.g., myTemplate.html), you set up the template to take an additional parameter to pass the computed value back.
<sly data-sly-template.myTemplate="${@ parameter, returnVariable=''}">
<sly data-sly-use.myModel="${'com.xxx.xxx.xxx.core.models.MyModel' @ parameter=parameter}" />
<sly data-sly-set.var="${myModel.method}" />
<sly>${returnVariable = var}</sly>
</sly>
Call the Template and Access the Variable
In the calling script (e.g., caller.html), you can call the template and use the returned value.
<sly data-sly-call="${myTemplate @ parameter='someValue', returnVariable=use.returnVariable}" />
<p>Computed Value: ${returnVariable}</p>
Notes:
- data-sly-template allows you to define reusable code blocks with parameters.
- data-sly-call is used to invoke these templates.
- By passing an additional parameter (returnVariable), you can capture the computed value from within the template and then use it in the calling context.
This method allows you to create a soft dependency where the logic resides within the template, and the calling context can access the results without directly dealing with the underlying Java model. It effectively separates concerns and avoids the need to include Java dependencies in multiple repositories.
