How should one use Granite UI foundation events to build a more dynamic dialog?

Question

I was searching for how to show/hide fields, whether a checkbox was checked or not.

So I found the following documentation: https://developer.adobe.com/experience-manager/reference-materials/6-5/granite-ui/api/jcr_root/libs/granite/ui/components/coral/foundation/clientlibs/foundation/vocabulary/toggleable.html

My understanding is that I can annotate a field with the “foundation-toggleable-control” class, and then when I press the field, a "foundation-toggleable-show" event will be dispatched.

Using a custom clientlib, I can listen to the event; however, the default behavior of the checkbox stops working.

Thanks.

AmitVishwakarma · Accepted Answer

Hi ​@gabrielfgmzkIn real‑world AEM projects you generally should not use foundation-toggleable-control for dialog show/hide. It's low‑level Granite vocabulary; when you wire it yourself you easily interfere with the component's built‑in behavior (e.g. checkbox click handling), which is why your checkbox stops working once you attach that class and your own listener.For Touch UI dialogs in AEM 6.5/Cloud Service, the recommended and battle‑tested patterns are:Use the standard cq-dialog show/hide pattern (no custom JS for simple cases)Add a CSS class on the controlling field, e.g.: granite:class="cq-dialog-dropdown-showhide" (or similar for a checkbox).On the target fields, add e.g. granite:class="productType-showhide-target" and granite:data="{ 'showhidetargetvalue': 'desiredValue' }".AEM's authoring clientlibs then handle show/hide automatically.This is the pattern described in many internal shares and the blog you were pointed to, and is considered best practice.For anything more dynamic, listen to foundation-contentloaded and use lightweight JSLoad a small dialog‑scoped clientlib via extraClientlibs on the dialog.On foundation-contentloaded, find your fields and attach Coral/Granite event listeners to control visibility.This follows Adobe's guidance for custom field behavior in dialogs and avoids hijacking core Granite events. See Handling Field Events and dialog clientlib guidance in Developing AEM Components and Creating a New Granite UI Field Component on Experience League for the recommended pattern:https://experienceleague.adobe.com/en/docs/experience-manager-65-lts/content/implementing/developing/components/developing-componentshttps://experienceleague.adobe.com/en/docs/experience-manager-65-lts/content/implementing/developing/platform/granite-ui-componentACS AEM Commons show/hide utilityFor more complex conditional logic, many teams successfully use the ACS Commons show/hide widgets utility instead of hand‑rolled Granite events:https://adobe-consulting-services.github.io/acs-aem-commons/features/ui-widgets/show-hide-widgets/index.htmlSo your understanding of foundation-toggleable-control isn't "wrong", but in AEM dialogs it's not the idiomatic or recommended way. Prefer the cq-dialog showhide pattern or a small dialog clientlib on foundation-contentloaded, and the checkbox's default behavior will remain intact.

BrianKasingli · Answer

I personally have not used `foundation-toggleable-control` to hide or show Granite fields in a Touch UI dialog. In most real AEM projects, the common approach is either using the built in `granite:class` and `granite:data` showhide pattern or listening to the `foundation-contentloaded` event and applying lightweight JavaScript.A pattern you will see frequently in tutorials and production projects is `granite:class="cq-dialog-showhide"` combined with matching `granite:data` on the target field. This approach is simple, widely adopted, and works reliably in Touch UI dialogs.A good reference that explains this common show and hide pattern across different field types is:https://blog.3sharecorp.com/show-and-hide-dialog-fields-based-on-any-field-typeYou will notice that most examples online follow this structure rather than using `foundation-toggleable-control`.When you move into more advanced use cases, such as hiding entire tabs based on a Style System selection, you typically need custom dialog logic. A more advanced tutorial that demonstrates this pattern well is:https://sourcedcode.com/blog/aem/aem-touch-ui-show-hide-tabs-by-style-system-configurationI would recommend going through multiple tutorials like these so you start recognizing the common patterns. The more examples you build, the easier it becomes to understand how custom Granite UI behavior is typically implemented in real AEM projects.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded