sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kunal Mittal (Jira)" <j...@apache.org>
Subject [jira] [Updated] (SLING-9174) Add option to replace component path to experience fragment variation path
Date Fri, 06 Mar 2020 13:42:00 GMT

     [ https://issues.apache.org/jira/browse/SLING-9174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kunal Mittal updated SLING-9174:
--------------------------------
    Description: 
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!

  was:
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=1770,height=956!


> Add option to replace component path to experience fragment variation 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: Dynamic-Include-Cache.png
>
>          Time Spent: 50m
>  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)

Mime
View raw message