Tomasz Niedźwiedź created SLING-7742:
----------------------------------------
Summary: Sling Dynamic Include Duplicates Selectors When
Components are Nested
Key: SLING-7742
URL: https://issues.apache.org/jira/browse/SLING-7742
Project: Sling
Issue Type: Bug
Affects Versions: Dynamic Include 3.1.2
Reporter: Tomasz Niedźwiedź
I'm using Sling Dynamic Include to optimise the caching of a static site.
Certain parts of our site are shared across all pages. For example, the header
is created in one place in the repository and every page that need it, includes
it using a special component.
We have configured SDI so that the component is replaced with an SSI tag. This
works fine and allows us to cache the header as a separate bit of HTML on the
AEM dispatcher.
{code:java}
<cached page html> ------SSIncludes----> <header html>{code}
In the SDI configuration, we use the {{shared}} selector as the
{{include-filter.config.selector}} for the particular resource type so when the
header is included, we get a request to
{{/content/mysite/en_gb/content/snippets/header.shared.html}}, so far so good.
However, when we introduce another reusable bit of HTML and us it inside the
header (therefore introducing nested components that are handled by SDI)
{code:java}
<cached page html> ----SSIncludes--> <header html> ---SSIncludes---> <main
navigation html>{code}
the {{shared}} selector is added twice. The page still renders correctly but in
the request log, as well as the dispatcher cache, we can see
{{/content/mysite/en_gb/content/snippets/header.shared.html}} (this is fine)
and
{{/content/mysite/en_gb/content/snippets/mainNavigation.shared.shared.html}}
(for instances where the {{mainNavigation}} snippet is used in the header), as
well as {{/content/mysite/en_gb/content/snippets/mainNavigation.shared.html}}
(for instances where the {{mainNavigation}} snippet is included by a page
directly).
This leads to unnecessary caching of the same markup.
While SDI is primarily intended for dynamic components, I think this is a valid
use case for it.
Before appending the selector determined by the {{filter.config.selector}}
property, SDI could check if the selector's already present in the selector
string. That way, we could nest our components, cache them in one spot and make
the invalidation quite simple.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
