Architecture Guidance for Redesign Multifiled dialog already having 2000+ Nodes in it. [AEM 6.5]

[tushaar_srivastava]

Hi Team,

I need an Architectural help to convert the multifield dialog of existing components with existing data in more optimize and efficent way.

recently I asked a question [Click here] where in my multifield there was around 3000~ nodes under the multifield which is not a good practise to put more than 1000 child nodes, but since it was the part of migration we migrated the fields under multifield and hence in some pages we got around 2500~ child nodes under multifield.

And while opening the dialog the UI breaks, and hence do not allow author to edit the component.

There was a solution I got is to increase the Number of Calls per Request from ConfigMgr under Apache Sling Main Servlet on requirement.

But change in configuration is not allowed after certain point.

So, I need help with some suggestion to change or redesign the component with the existing values.

Thanks

@kautuk_sahni  @arunpatidar  @lukasz-m  @EstebanBustamante 

[aanchal-sikka]

@tushaar_srivastava 

Are these many values needed in multiple pages? Or is it configured in one page and then referenced in other places?

[EstebanBustamante · Accepted solution]

Hi,

The issue lies with the UI. While AEM (JCR) can handle the quantity of nodes you have, the UI struggles to process this amount of data efficiently. Therefore, I would assume that this issue may arise if you use other visual data structures such as ACS common list. Here are some recommendations for your definitive final solution:

• Assess where this information will be used. Is it shared by multiple components? Is it leveraged by the BE components? Is it consumed by the front end?
• Refine the taxonomy. Break down and group the nodes into smaller chunks. I am not sure what the information is about, but for example, if it pertains to dates, you can break it down by year, month, day, etc. Be cautious about the taxonomy as it could become tricky and critical, especially if you start using queries.
• Determine how frequently this information will be changed or updated by an author. If it truly needs to be updated by an author.

Based on the analysis of these factors, you can determine:

1. If this data really needs to reside in AEM.
2. If it needs to be authorable.
3. What level of usage and visibility you require.

With this understanding, you can explore various options for making the swap, such as a component, a datasource, ACS commons, a plain file, a CSV file, an external service, etc.

Hope this helps.

[EstebanBustamante]

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

[tushaar_srivastava]

Hi @EstebanBustamante ,
Thank you so much for your reply, I am analysing the approach you suggested.
I will share the information once I get the excat resoultion.
Though, I am thinking to put all values in Excel and use that excel from /content/dam and iterate each node in order to utilise it as values.