Show/Hide in style system based on selection inside component dialog

[shafali12]

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.

Any suggestions for this will be helpful,

Thanks in advance.

@Imran__Khan @arunpatidar @aanchal-sikka @Rohan_Garg 

[HrishikeshKa]

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:

1. Component Dialog Setup:

   • Ensure that your component dialog includes a dropdown select field where users can choose between options A and B.

2. Define Style Groups:

   • In your style system, create the necessary style groups for both A and B, as well as any common style groups that should always be visible.

3. Scripting or Plugin Development:

   • Depending on the capabilities of your design tool, you may need to use scripting or develop a plugin to handle the dynamic show/hide functionality of style groups based on the dropdown selection.
   • For example, if you're using Sketch, you might need to develop a Sketch plugin using JavaScript to manipulate the visibility of style groups based on the dropdown selection.

4. Interact with Style System:

   • Your script or plugin will need to interact with the style system to toggle the visibility of specific style groups.
   • This might involve accessing the style groups by name or some other identifier and setting their visibility property accordingly.

5. Testing and Refinement:

   • Once you've implemented the functionality, thoroughly test it to ensure it works as expected in both the component dialog under the styles tab and under the paintbrush section for that component.
   • Refine your implementation as needed based on user feedback and any edge cases you encounter during testing.

6. Documentation and Support:

   • Provide clear documentation or instructions for users on how to use this feature.
   • Offer support channels in case users encounter any issues or have questions about the functionality.

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.

[shafali12]

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 ?

[HrishikeshKa]

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:

1. APIs or SDKs:

   • Investigate whether your design tool provides APIs or SDKs that allow programmatic access to style groups and their properties.
   • Look for methods or functions within these APIs that enable you to query or manipulate style groups based on their names, properties, or other attributes.

2. Naming Conventions:

   • If unique identifiers are not available, consider establishing naming conventions for your style groups that can be programmatically recognized.
   • For example, you could prefix or suffix the names of style groups with specific keywords or patterns that your script or plugin can detect and act upon.

3. Metadata or Attributes:

   • Check if your design tool supports adding metadata or custom attributes to style groups.
   • You may be able to tag style groups with custom metadata or attributes that your script or plugin can use to identify and interact with them.

4. Index-based Access:

   • If all else fails, you might resort to index-based access if your design tool provides functionality to iterate over or query style groups in a sequential manner.
   • While less robust than using unique identifiers, this approach could still work if style groups are consistently ordered or categorized in a predictable manner.

5. Tool-specific Solutions:

   • Explore online communities, forums, or documentation specific to your design tool for potential solutions or workarounds.
   • Other users or developers may have encountered similar challenges and devised creative solutions or plugins to address them.

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.

[BrianKasingli]

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

[shafali12]

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.

[avesh_narang]

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 !

[Rohan_Garg · Accepted solution]

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.

[Rohan_Garg]

++ @EstebanBustamante 

[EstebanBustamante]

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 

[Shashi_Mulugu]

@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.