Monday, 28. September 2020 13:30 - 13:50 (20 min)
Resource Mapping has been around in Sling from the first days. We all have worked with either simple JcrResourceResolverFactoryImpl configs and/or more complicated /etc/map-Setups. To make it more interesting we have fought our way through Apache rewrite rules, farm configurations and correct de-caching, http vs. https issues (luckily today it's almost always https only!) and tenant-unique vanity paths (when Sling only knows them per server instance). We have adjusted links using String operations and we have gotten it sometimes wrong (because there is always this one special link incarnation we didn't think of during implementation).
Now all that will not completely go away with the new Resource Mapping SPI, but yet our life becomes easier:
- Introducing the interface ResourceURI (with a backing helper class for everybody to use) helps simplifying code around link handling
- Extending the mapping process via a well-defined API that allows to write Turing-complete code is often more flexible and than the current purely declarative approaches (config for JcrResourceResolverFactoryImpl or /etc/map) - a flexibility that is otherwise only possible Rewriting Pipelines
- In HTL there there is an option to automatically map all attributes of display context uri. With this new approach many setups can do without the Rewriting Pipelines (that come itself some limitations) which is a great opportunity to improve performance. Also debugging gets easier since the mapping happens directly and is not decoupled via the response output stream.
The talk will show some examples on how to extend the resource mapping via the new API and how to configure the AEM to make use of it.