AEMaaCS how to dynamically create editable component items

[aderler]

We are working on a solution to what we call the "pagelist", which is a custom component based on the "list" core component.

Using the custom component it is possible to either render a fixed list of pages or search for pages dynamically (for example based on tags). This part can be done quite easily.

The challenge we are facing, however, is that it should be possible to edit each item individually. That is, it should be possible to edit each list item individually in the editor (for example, setting a specific background color for an individual item).

To this end, in our current solution we have created a separate component for an individual list item, which we call "pagelistitem". That means, the parent list creates a child resource for each list item dynamically in the Java component model and then in the HTL template we simply render all the child resources (using data-sly-resource). As a result, since the child resource is itself a separate component, it is easily possible to edit each item individually.

However, we are now facing the issue that dynamically creating child resources on publish instances is generally not possible in the cloud environment.

As a result, our approach does not work with that restriction. Since the list items can be retrieved dynamically (e.g. via tag search), the list items can always change in comparison to the state when it was last created or updated on the author instance in the page editor.

Consequently, we are now searching for an alternative approach to tackle this issue. 

We were not really able to find a clean approach to solve this issue, the only approach that we were able to identify was to differentiate between the author/publish run mode in the Java model and during rendering. However, this does not seem like the optimal solution.

So the question here is, if there is an alternative approach to dynamically create editable components in the cloud environment. Any help is very appreciated. Thank you in advance!

[Jörg_Hoh · Accepted solution]

Hi,

from what I understand you create dynamically sub-nodes in the repository, which show up as dedicated components in the page. This requires you to write to the JCR repository. You do this during page rendering, and doing that causes problems because anonymous does not have write permissions on publish. Is my understanding correct?

From my point of view, the unique thing of a list component is that all list items are identical. Same formatting, same background etc. The items are also often taken from some other place (eg list of sub-pages etc), so it's not something you maintain manually.

If you want to maintain and format something manually, you should use a standard rich-text component. It offers you just that. I wonder what's the benefit you get from the standard list component if you customize it that much.

But if you want to populate list entries dynamically, why do you store them as subnodes in the repository? The list component itself is capable to display entries based on various criteria, including search and tags (https://experienceleague.adobe.com/docs/experience-manager-core-components/using/components/list.htm...).

[aderler]

Hi, thanks a lot for your answer.

Yes, correct. This is exactly the problem we are facing. Since dynamically creating sub-nodes can be done on the author, this also works as long as the page is rendered on the author instance (the sub-nodes will be created) and then publishing the page, since the sub-nodes will also be copied.

Regarding the requirements, the main advantage of using a list component vs using a rich text is that the entries can be queried and retrieved dynamically. For example, "list all pages with tag 'corona'". When adding a new page with this tag, the page will automatically be part of the list, without any need to manually add it there. Another scenario is just to list all sub-pages of a specific node. Similarly, when adding a new sub-page to the node, it will automatically rendered as a list item. Since, we are dealing with lots of pages that are created regularly, this makes managing lists of pages much easier for editors.

[Jörg_Hoh]

But if you want to populate list entries dynamically, why do you store them as subnodes in the repository? The list component itself is capable to display entries based on various criteria, including search and tags (https://experienceleague.adobe.com/docs/experience-manager-core-components/using/components/list.htm...).

[aderler]

@Jörg_Hoh The subnodes are created dynamically, since we want each subnode to be editable in the editor on the author. The requirement is that it should be possible to override the data retrieved via the search. For example, an image is rendered for each item. It should be possible to override the image of the item with some custom cropping or adding an alternative image. That is one use case why we created a resource by default, so the editor can select each item and each image and edit them individually. In general, we found a solution for this problem by creating a resource in the memory, but not committing it to the JCR tree. That allows us to render editable items, which will be persisted to the JCR tree, only when there is customization. Since no resource will be persisted by default, we no longer have any issue on the publisher, since we do not need write access.

[Jörg_Hoh]

I don't really understand that requirement (it sounds weird to me to render the results of a search with the chance to adjust it manually, because the search result in general is quite dynamic and can change when new content is added or existing content changed or removed. But if you made it work for your case: Good job!