adobe
Enable eDAM on Core Container Component
Feature Request
Is your feature request related to a problem? Please describe. As an author, I would like to be able to select assets from a remote EDAM when using the Core Container Component.
Describe the solution you'd like Extend the current functionality of Core Container Component v1 (upgrade to v2) and implement remote assets selector functionality, similarly as it is implemented in the Image v3 component.
Are there alternatives? An alternative is to implement a customization on the client side, but ideally, it is better to have it implemented OOTB here at the core component level.
Documentation The users will be able to open the container component author dialog, navigate to the properties tab, and then, in the background image picker, select the pick dropdown box, which will allow two options: Local and Remote. The Local option will allow the user to select from the local DAM repository. The Remote will allow to open the Assets Selector Frontend app and browse and login to the remote EDAM and then browse and search for remote dam assets. Then select one and see thumbnail generated and than save the dialog and the remote dam image will be rendered as a background style image.
This is effectively the same as the long-standing https://github.com/adobe/aem-core-wcm-components/issues/741 - ultimately to fix the Container component needs to be refactored to enable the imageDelegate pattern and reuse the image dialog widget.
Also this issue duplicates https://github.com/adobe/aem-core-wcm-components/issues/2941
@HitmanInWis - thanks for pointing out the duplicate issues. I agree that the long-standing #741 is a better approach for a container web-optimized background image. From a short-term solution, the https://github.com/adobe/aem-core-wcm-components/issues/2941 is the way. Well, I am gonna work (with my team) on the implementation and see where we end up and issue a PR.
I think if you solve this the way I recommend above (use the ImageDelegate pattern that Teaser uses, and update the Container dialog to use the image dialog widget) then you'll solve both use cases. The crux of the issue is that the image inside of the Container object should be handled in the authoring dialog the exact same way it is handled by the standalone Image component, so that you achieve and maintain feature parity for this feature as well as future enhancements.
(FWIW this is how I've solved it on my projects)
You solved it? What stopped you from contributing the code here? :)
(FWIW this is how I've solved it on my projects)
You solved it? What stopped you from contributing the code here? :)
I've been pretty outspoken for years that extending/overlaying WCM Core components is a fragile and limiting practice, so my solutions are applied to highly modified versions of WCM Core code and thus not as readily contributable. There are many open issue where I've provided the code fix in comments. This one is definitely a bit more involved. 😄