Extend Core components to display content from a linked CF
Use-case:
Many clients want to reuse content across multiple channels. Often recommendation is to use content fragments for authoring. However, being form-based, it cannot readily be used on a website. It would be good if we could extend core components such that they can display content from a linked CF
Current/Experienced Behavior:
CF being form-based cannot readily be used on web-pages
Improved/Expected Behavior:
Components should be able to pull content from a linked CF to display
Environment Details (AEM version/service pack, any other specifics if applicable):
Are we proposing the idea of letting users choose single or multi element values from the linked cf as part of generating the content for cf linked in the actual page? I think this is probably possible if a child cf is generated as a nested component. Or else this may lead to potential of a nested reference issue or dialog may become too complex if not restricted through some hierarchical level policy. I am sure some of these challenges are regardless of whether we use headless or headful approach, but authoring may still be an issue with the current design.
I am proposing to author content in CF. Then use this CF to render say Teaser component on AEM Site and also expose via GraphQL for multi channel support.
So, in a way all/majority of the content is created in CF, and reused across AEM sites (headful) and other channels (headless).
It would definitely need a way to map dialog fields with CF fields.
Thanks for sharing. This is on point to a feature I am working for spa. For typical content rich components we want to use core comps as is so only write react code for those comps. But to avoid custom components (nodes and dialogs) I took a route to use content fragments instead. So using a cf model and cf I have data available and can use cf container on page to transmit the data via model.json and the same be consumed by react component without creating a brand new map to but an internal mapto using cf model path.
Now I see your point that regardless of the component if the cf fields match to the target component be it a simple teaser or a complex one like login component, the cf needs to be transform itself i.e. The integration you are proposing should do that based on component type. The only issue I see here is associations or integrations at multiple level. Today core comps are rendering based on sling model interface design i.e. The interface expects so and so props for the comp to render from the impl available. Now with cf association there needs to be a provider that binds cf data into this model before rendering markup. Not saying it's not feasible but too many layers to keep it tightened. In my thoughts it should be something like this. Generic solution to address all these touch points would be great but the way I see it some major design changes or enhancements needs to be come in for giving such a seamless developer and authoring experience. Feel free to share your thoughts
This has been reported to the engineering under the internal reference SITES-16113. The product team will triage this request to verify feasibility based on the prioritization model. This post will be updated according to the Jira request status.
