Is their any way to show/hide groups in style systems based on the selection inside component dialog.
Requirement :Inside component dialog we have a dropdown select field, on selection of A, we need to show 2 style groups that are specific to A and on selection of B the style group related to B should be visible and that related to A should be hidden and some style groups are common for both A & B which will always be visible.
This functionality should work, both inside dialog under styles tab and under paintbrush section for that component.
Solved! Go to Solution.
Views
Replies
Total Likes
Hi @shafali12,
Selection and show/hide of dialog fields based on style systems is a straight forward scenario.
But the other way round is rather tricky & poor design - You will have to write a custom JS which targets the coral ui icon for styles and manually removes the style options based on your logic for dialog field selection.
This is rudimentary but I don't see an alternative approach as styles are applied based on content policy nodes for the template thereby having precedence over the dialog's behavior.
Hi @shafali12 ,
To achieve the functionality of showing/hiding style groups in a style system based on the selection inside a component dialog, you'll likely need to utilize a combination of design tools and possibly scripting or plugin development, depending on the software you're using. Here's a general approach you could take:
Component Dialog Setup:
Define Style Groups:
Scripting or Plugin Development:
Interact with Style System:
Testing and Refinement:
Documentation and Support:
Remember to consider the specific capabilities and constraints of your design tool when implementing this functionality, as the exact approach may vary. If you're using a tool like Sketch, Figma, Adobe XD, etc., you might find existing plugins or scripting resources that can help you achieve this functionality more efficiently.
Hi @HrishikeshKa
Thank you for the reply
But as per your 4th point : for accessing/interacting style groups we are not getting any unique identifiers from the dom structure apart from styleIds which is a blocker for us. Any suggestion on it ?
Hi @shafali12 ,
If you're unable to directly access or interact with style groups using unique identifiers from the DOM structure, you may need to explore alternative approaches depending on the capabilities of your design tool and the available APIs. Here are some potential strategies you could consider:
APIs or SDKs:
Naming Conventions:
Metadata or Attributes:
Index-based Access:
Tool-specific Solutions:
Ultimately, the feasibility of these strategies will depend on the capabilities and extensibility of your design tool's API and scripting environment. Experimentation and iteration may be necessary to find the most effective approach for your specific use case.
I have created a blog article for this problem in the past. I have provided detailed tutorial on how to hide tabs based on style systems selected by the content author.
How the solution works:
The AEM developer will add code configurations to the cq_dialog.xml which targets one or more tabs with some special properties and nodes like the “granite:class” and the “granite:data”. After configuring these properties and nodes within the cq_dialog.xml, all tabs will be hidden as the initial rendering phase (during configuration of the component), Upon selection of a Style System, the tabs will be visible based on the matched configuration that is set under the granite:data node properties, based on the StyleSystem CSS class that was set.
Read more: AEM Touch UI Show Hide Tabs by Style System Configuration - Sourced Code
Hi @BrianKasingli
Thank you for the reply
But here our requirement is vice-versa depending upon the dropdown changes inside component dialog need to show/hide styles inside Style-System. So like “granite:class” and the “granite:data” that we are passing for dialog, can we pass any custom attr for styles/groups inside Style-System.
Style system rendering logic lies here : /libs/cq/gui/components/authoring/styleselector
Overlay and add the business logic to get desired output.
Hope this helps !
Hi @shafali12,
Selection and show/hide of dialog fields based on style systems is a straight forward scenario.
But the other way round is rather tricky & poor design - You will have to write a custom JS which targets the coral ui icon for styles and manually removes the style options based on your logic for dialog field selection.
This is rudimentary but I don't see an alternative approach as styles are applied based on content policy nodes for the template thereby having precedence over the dialog's behavior.
Hi @shafali12
The short answer is no. The problem is that what you are trying to do is conceptually wrong. The idea behind the style system is to leverage functionality at the template (policies) level. This is a completely different approach compared to having dialog configurations that are component-scoped. Mixing these scopes, as @Rohan_Garg stated, is tricky and incorrect. I wouldn't advise going that route.
Although technically you could achieve this through some workarounds using custom JS or a servlet that updates policies on the fly, this would still be wrong as mentioned a couple of times.
My advice is to understand the usage of the style system, comprehend what it is intended for, and check if it meets your requirements. It seems it does not. In that case, you could go back and inform your client about the intended features and their limitations, OR you could abandon the style system and keep everything at the dialog level. This is the old and traditional way to provide options to authors based on selections, similar to this: Show/Hide AEM CQ Dialog Fields Based on Select Field Selection: A Comprehensive Guide.
Hope this helps
@shafali12 Did you find the suggestions from users helpful? Please let us know if more information is required. Otherwise, please mark the answer as correct for posterity. If you have found out solution yourself, please share it with the community.