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!
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
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...).
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...).
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.
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies