How to map Node properties on the fly to use with AEM default List component?

0
votes

I'm trying to port custom component to out-of-the-box List component in AEM 5.6.1. Custom component keeps its settings in the node properties which names are different from what com.day.cq.wcm.foundation.List is expecting.

For example: custom component has a tag filter implemented and its values stored in the property named "featuredTags", OOTB List component is looking for the property named "tags" (JavaDoc).

Is there a way how to populate or map such properties on the fly without updating repository?

Implementation details:

  • I overlay /lib/foundation/components/list component in /apps/foundation/components/list which is mainly a container with sling:resourceSuperType set to /libs/foundation/components/list and two custom views added

  • I have also another component under /apps/ < myapp > /components/publicationList which has sling:resourceSuperType set to foundation/components/list effectively extends /apps/foundation/components/list component

  • under publicationList dir I have init.jsp where I put custom logic list initialization.

And here comes the problem. Since /apps/ < myapp > /components/publicationList already existed before and was completely independent from the OOTB list component it has its own config parameters assigned in multiple instances of that component used in different pieces of content. It didn't use com.day.cq.wcm.foundation.List before and used Xpath query to extract data from repo.

What I'd like to do is to leverage OOTB functionality (implying com.day.cq.wcm.foundation.List utilization) for that old component. And the question is how I can "emulate" certain property of the node using value of another property without actually changing the repository? com.day.cq.wcm.foundation.List takes SlingHttpServletRequest for initialization so whatever I do with the Node (adapted from the current resource) is not presented in the scope used for List initialization. I don't want to actually write into repository during runtime (for performance and security reasons) and wanted to avoid background update of the repo information - system is live and old component is being used by multiple authors.

Any ideas?

1
adobeaemjcr
First: Why do you overlay the foundation first and not just use the inheritance like in your existing list component? And with sling:resourceSuperType, you ommit the first part of the path "/libs/" or "/apps/" thus an overlay using the supertype would be recursive. – Thomas
@Thomas - we still need to customize foundation component in order to add custom views but still use ootb functionality. The idea is to amend legacy components by adding thin proxy layer (custom init.jsp) and parse old properties switching them into the List properties on the fly. That's why we have two subsequent overlays - legacy component overlays customized list component which overlays ootb list component. And what did you mean by "inheritance"? – Jura Khrapunov
Maybe I don't understand your requirement or you not yet take full advantage of sling:resourseSuperType. This is what I meant with inheritance. In your case, I wouldn't overlay the foundation component, but create multiple components in your app folder. The top most (e.g. /app/myapp/components/list) inherits (sets sling:resourceSuperType="foundation/components/list"). Then there is another component with sling:resourceSuperType="myapp/components/list" In each component you just override the required part, e.g. the jsp but reuse the dialog. issues.apache.org/jira/browse/SLING-278 – Thomas
Actually, that is exactly what i'm doing. I have head component which inherits foundation list properties (using sling:resourseSuperType) and overlaying some of its files, for example pagination (which is not i18-ed in original component) and adding few custom views. The main problem I'm trying to resolve is how to let EXISTING nodes, created via legacy custom List components, use ootb component since existing properties (already set in JCR) do not correspond with the properties expected by List component/class – Jura Khrapunov

1 Answers

0
votes

Now that I understand the requirement, I try to give an answer. I think the only feasable way is to write a "migration" script, that changes the legacy property to a compatible property name and/or format. You can do that in a JSP with a few lines of code. Just query all components using the legacy list resourceType and change the properties of all components.