data-sly-resource - hiding dialog fields?

[jakej40603950]

Hello, 

When you're inheriting from another component using sling:resourceSuperType you can hide certain dialog fields using hideResource, hideProperties, etc.

Is it possible to hide dialog fields when you're embedding (not inheriting) one component into another using data-sly-resource? E.g. if you're including component A in component B using data-sly-resource is it possible to hide some of the dialog fields of component A without having to write custom clientlib/js?

Thanks for any inputs on this.

[2490242973]

like

[BrianKasingli]

Since you are calling data-sly-resource, then the targeted component will re-use the target component's Touch UI configuration. If you wish to remove some fields to the target component, then you'd need to override the component's Touch UI itself. And so, if you extend the component's Touch UI itself, you utilize AEM component granite:hide="${cqDesign.myCustomProperty}" to have granular control on what is visible or not based on the template policies.

[BrianKasingli]

Since you are calling data-sly-resource, then the targeted component will re-use the target component's Touch UI configuration. If you wish to remove some fields to the target component, then you'd need to override the component's Touch UI itself. And so, if you extend the component's Touch UI itself, you utilize AEM component granite:hide="${cqDesign.myCustomProperty}" to have granular control on what is visible or not based on the template policies.

[aanchal-sikka]

Hello @jakej40603950 

Option-1: Use javascript to hide-fields

Option-2: If you are able to use a container to encapsulate the componen tA and B, you can define the policy of componentA specifically for this container. The policy or cqDesign config can then be used to hide fields.

https://experienceleague.adobe.com/docs/experience-manager-65/developing/components/hide-conditions....

[yuriy_shestakov · Accepted solution]

We usually don't write dialogs in HTL so don't use the data-sly-resource for including dialogs.

Our usual way of implementing what you need, but when all the dialogs are just cq:dialog nodes, it is using the approach from ACS Commons Parameterized Namespace Granite Include (using their code or writing our own similar request filter for parameterizing include). Then we use the `granite:hide` attribute to hide the piece of dialog when the provided boolean parameter is set to true.

If your dialogues are still HTL.

If that partial of a dialog that you include is your own dialog piece, then you should have full control over it so you can pass some custom properties when including, and use that property to show/hide fields. However, you will have to use data-sly-include instead of data-sly-resource, and pass the properties using the requestAttributes param. Those request attributes you passed can be extracted in Java code (also server-side JS), then exposed to HTL through a model (or JS use object), and used in data-sly-test constructions.
To create the attributes map you can use either Java or server JavaScript code, for example like here: https://gist.github.com/dlh3/248aa56ba7301f65e29f435c7cb03de0

Actually, I couldn't understand how you planned to use data-sly-resource for including the dialog, as when you have a dialog you still don't have a resource, and with using data-sly-resource you can't include a resource from /apps by its full path, and including using a relative path also won't work as if you create such nodes it can break your dialog. At least I tried that some time ago and it didn't work.

Also, as your dialog code is HTL, you can use the HTL templates instead, where you can add any number of parameters and also change the output code the way you need.

If the data-sly-resource would work with dialogs, I would suggest trying also the `addSelectors` parameter - you can have several variations of your dialog component in different files with selectors that you can use in your data-sly-resource directive.

I suggest writing your dialog component in HTL with some kind of configuration in a child item as it is for the dialog datasource component, or in the current node parameters, the same way it is used in other granite coral components. Then create a piece of XML to include, containing just this single component but with different configurations in ACS commons ${{}}-syntax, And leverage that ACS Commons include feature for including it in many places where necessary, without using HTL data-sly- resource thing.