[
https://issues.apache.org/jira/browse/SLING-9174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248366#comment-17248366
]
Achim Koch edited comment on SLING-9174 at 12/12/20, 3:59 PM:
--------------------------------------------------------------
Hi [~kmittal],
I think the problem is not, that Sling-folks do not understand your
explanation, but your solution is not in accordance with the Sling/AEM
architecture:
AEM is at a higher level of abstraction in the stack.
AEM uses Sling. Thus AEM can use the Sling API.
Sling, being on the level below is not aware that AEM even exists. And it must
not assume that certain components or resource types are there. That would make
Sling additionally dependent on AEM which kind of represents a circular
reference (although not a hard dependency).
I am 100% with you, that SDI can provide a performance optimisation in
accordance with XFs.. but this can be solved in AEM as follows:
You do not define the SDI include for the XF component in the
"/content/mybrand" tree, but on the XF-page itself, below
/content/experience-fragments with an additional configuration (SDI provides a
factory)
!2020-12-12_15-44-21.png!
This would create an SSI URI for the XF Component as embedded in the page but
for the included XF Page at its origin.
This works OOTB:
!2020-12-12_16-56-21.png!
was (Author: -achim):
Hi [~kmittal],
I think the problem is not, that Sling-folks do not understand your
explanation, but your solution is not in accordance with the Sling/AEM
architecture:
AEM is at a higher level of abstraction in the stack.
AEM uses Sling. Thus AEM can use the Sling API.
Sling, being on the level below is not aware that AEM even exists. And it must
not assume that certain components or resource types are there. That would make
Sling additionally dependent on AEM which kind of represents a circular
reference (although not a hard dependency).
I am 100% with you, that SDI can provide a performance optimisation in
accordance with XFs.. but this can be solved in AEM as follows:
You do not define the SDI include for the XF component in the
"/content/mybrand" tree, but on the XF-page itself, below
/content/experience-fragments with an additional configuration (SDI provides a
factory)
!2020-12-12_15-44-21.png!
This would create an SSI URI for the XF Component as embedded in the page but
for the included XF Page at its origin.
This works OOTB:
> Add option to replace component path to content path
> ----------------------------------------------------
>
> Key: SLING-9174
> URL: https://issues.apache.org/jira/browse/SLING-9174
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: Dynamic Include 3.1.6
> Reporter: Kunal Mittal
> Priority: Major
> Attachments: 2020-12-12_15-44-21.png, 2020-12-12_16-56-21.png,
> Dynamic-Include-Cache.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The SDI module currently includes the path of the component in the SSI
> directive which creates the cache under the page where the component is
> added.
> There are number of cases where we create content which gets reused across
> the website. In order to achieve reusability, we create proxy components
> which in turn makes a call to the reusable content pages.
> *EXAMPLE*
> Proxy component: banner-proxy
> Reusable content page: /content/sdi/us/en/content/banner
> Pages: /content/sdi/us/en/test-sdi1, /content/sdi/us/en/test-sdi2
> The banner-proxy component exists on both pages: test-sdi1 and test-sdi2 page
> to render /content/sdi/us/en/content/banner.
> If we enable SDI and enable caching for banner-proxy component then 2 cache
> entries get created:
> /content/sdi/us/en/test-sdi1/_jcr_content/root/banner-proxy and
> /content/sdi/us/en/test-sdi2/_jcr_content/root/banner-proxy
> When any change is made to /content/sdi/us/en/content/banner page, it should
> reflect the changes on test-sdi1 and test-sdi2 page for which we need to
> write extra code to find the occurrences of where the proxy banner component
> is used to evict the cache.
> With the enhancement the SSI directive includes the path of the content:
> /content/sdi/us/en/content/banner, the system creates a single cache entry
> for the page that is referenced. By having the SSI component included by
> reference, any updates to the parent page are reflected in the including
> pages, removing the need to re-render or update each including page
>
> *Benefits*:
> # Performance
> ** Considerably reduces the number of calls to the server
> # Cache Optimisation
> ** No custom code to invalidate cache entries created under every page
> *Current implementation*:
> {code:java}
> ## Directive added in the page after processing of SDI
> <!--#include
> virtual="/content/sdi/us/en/test-sdi1/_jcr_content/root/banner-proxy.nocache.html"
> -->
> {code}
> *Enhancement*:
> {code:java}
> ## Directive added in the page after processing of SDI
> <!--#include virtual="/content/sdi/us/en/content/banner.content.nocache.html"
> -->
> {code}
> Below are the differences when it comes to caching:
> !Dynamic-Include-Cache.png|width=834,height=451!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
