The purpose of the sling dynamic include (SDI) is to replace dynamic generated components (eg. current time or foreign exchange rates) with server-side include tag (eg. SSI or ESI). Therefore the dispatcher is able to cache the whole page but dynamic components are generated and included with every request. Components to include are chosen in filter configuration using
resourceType attribute.
When the filter intercepts request for a component with given
resourceType, it'll return a server-side include tag (eg. <!--#include virtual="/path/to/resource" --> for Apache server). However the path is extended by new selector (nocache by default). This is required because filter has to know when to return actual content.
Components don't have to be modified in order to use this module (or even aware of its existence). It's servlet filter, installed as an OSGi bundle and it can be enabled, disabled or reconfigured without touching AEM installation.
Let's try ☺
Lets do this practically by loading a component with and without SDI.
Component without SDI:
Load the page without configuring SDI and check the view source.
Configure SDI:
 |
| SDI Configuration |
Filter is delivered as a standard OSGi bundle. SDI is configured via the configuration factory called SDI Configuration.
In above screenshot, I have enabled SDI and entered base path and the component to be included using SDI. I have selected include type as Javascript. So in view source we can observe that component is replace with Javascript code.
Following properties are available:
- Enabled - enable SDI
- Base path - given SDI configuration will be enabled only for this path
- Resource types - which components should be replaced with tags
- Include type - type of include tag (Apache SSI, ESI or Javascript)
- Add comment - adds debug comment:
<!-- SDI include (path: %s, resourceType: %s) -->to every replaced component - Filter selector - selector used to get actual content
- Component TTL - time to live in seconds, set for rendered component (require Dispatcher 4.1.11+)
- Required header - SDI will be enabled only if the configured header is present in the request. By default it's
Server-Agent=Communique-Dispatcherheader, added by the AEM dispatcher. You may enter just the header name only or the name and the value split with=. - Ignore URL params - SDI normally skips all requests containing any GET parameters. This option allows to set a list of parameters that should be ignored in the test. See the Ignoring URL parameters section in the dispatcher documentation.
- Include path rewriting -- enable rewriting link (according to sling mappings) that is used for dynamic content including.
Component with SDI (Javascript):
Now configure the SDI include type as "Javascript". Reload the page and go to view source.
In view source we can observe that SDI script is included.
<!-- SDI include (path: /content/sightly-test/_jcr_content/par/langcomp.nocache.html,
resourceType: sightlyProject/components/content/langComp) --> <div id="dynamic_include_filter_div_1007"></div> <script type="text/javascript"> jQuery.get("\/content\/sightly-test\/_jcr_content\/par\/langcomp.nocache.html", function(data) { jQuery("#dynamic_include_filter_div_1007").replaceWith(data); }); </script>
 |
| Component loaded with SDI (Javascript) |
Component with SDI (Apache SSI):
Now configure the SDI include type as "Apache SSI". Reload the page and go to view source.
In view source we can observe that SDI script is included.
<!-- SDI include (path: /content/sightly-test/_jcr_content/par/langcomp.nocache.html,
resourceType: sightlyProject/components/content/langComp) -->
<!--#include virtual="/content/sightly-test/_jcr_content/par/langcomp.nocache.html" -->
 |
| Component loaded with SDI (Apache SSI) |
How to test sling dynamic include:
Lets test sling dynamic include with Apache SSI. In order to test this
- first configure dispatcher, if not configured see here to confiure dispatcher.
- Enable SSI in Apache & dispatcher, click here to see the configs.
- Now bring up your dispatcher.
 |
| Dispatcher is up and running |
 |
| Testing without SDI |
 |
| Testing with SDI (Apache SSI) |
Benefits:
As SDI components are loaded at runtime, remaining page is loaded from dispatcher cache page will load faster.
 |
| Load time without SDI |
 |
| Load time with SDI (Apache SSI) |
If SDI is not working, then check the below things:
- Check if all the configurations are done correclty.
- In configMgr, check if resource type is not appended with either /apps/ or /libs/.
References:
No comments :
Post a Comment