adobe / aem-core-wcm-components

Standardized components to build websites with AEM.
https://docs.adobe.com/content/help/en/experience-manager-core-components/using/introduction.html
Apache License 2.0
730 stars 736 forks source link

[Link Handling] Externalizing Links without CQ Externalizer #63

Open stefanseifert opened 6 years ago

stefanseifert commented 6 years ago

Using the CQ Externalizer for externalizing links is very inconvenient. By default it supports only one Author and one Publish URL. It is possible to provide further URLs by providing a third argument to the externalizer method, but this requires hard-coding this argument in the code (or making it configurable on some custom location in the site).

The core components make use of the Externalizer without passing a third argument, making the affected components unusable of more than one site is used on the AEM instance. Currently this affects directly only the social sharing component.

What would be required would be a possibility to configure the link externalizing per site (ideally using Sling Context-Aware Configuration), or to be able to plugin you own externalizing logic via an OSGi service. An example for a much more sophisticated solution is the wcm.io URL Handler, which is using Author/Site URLs configured via Sling Context-Aware Configuration under the Hood.

richardhand commented 6 years ago

+1 this has been added to our roadmap

alexkli commented 6 years ago

I assume you are trying to use the externalizer for foreign services, not AEM itself? Note that the externalizer is not designed for that. It's meant for externalizing AEM URLs = taking an "internal" JCR path and make it reachable from an external location (so to speak). Some methods use the sling reverse mapping which doesn't make sense for 3rd party services.

With an AEM deployment, you usually have a fixed set of environments, say the live site (publish), the authoring (author) (default domains), and maybe some custom production environment that one might want to link to. In that case components might only be configured to what domain string (e.g. author or publish) to use when calling Externalizer.externalLink() using e.g. Sling CA configuration, but not to an arbitrary number.

justinedelson commented 6 years ago

@alexkli I don't think that's the use case. The specific use case in the core components is that the og:url meta tag used by the social sharing component is required to be an absolute URL back to the current page (not unlike the canonical link tag). So this is a (at least IMO) reasonable use for the Externalizer. The problem highlighted by @stefanseifert is that with the Externalizer, the caller (i.e. the social sharing component) needs to know which domain argument to pass in and in a multi-domain environment this has to be configured somewhere. Agree that using CAConfig to define this domain argument would be a viable solution.

stefanseifert commented 6 years ago

bq. With an AEM deployment, you usually have a fixed set of environments, say the live site (publish), the authoring (author) (default domains), and maybe some custom production environment that one might want to link to. usually you have not only 1 site in an AEM instance, but multiple (dozens, hundreds, thousands of sites for the big customers). you need different Site URL configurations for each of them. this is not maintainable using the AEM built-in externalizer. this affects not only the core components, but all AEM applications.

use cases for externalizing links within AEM applications beyond the core components are for example:

alexkli commented 6 years ago

@stefanseifert I see, makes sense. The impact of MSM and hosting many sites with completely different hostnames didn't reach the externalizer so far 😄

I believe a simple extension might be to have an externalize() method that can take a URI (as string) instead of a domain, e.g. https://siteA.com or https://siteB.com or even https://siteC.com/path.

It would still leave the configuration aspect (e.g. Sling CA) to the client of the API, but at least one doesn't have to reimplement the externalize logic (which is actually quite tricky with certain encodings and proper URI parsing).

gabrielwalt commented 6 years ago

(CQ-4221425)