1 person found this helpful
As a general rule anything you manage in CQ gets published to the web server via the Dispatcher plugin. Dispatcher functions as a reverse proxy sending request back to the publish servers and caching the result.
As far as managing the .shtml items I am assuming that you want them to be generated and managed as pages in CQ with traditional component authoring interfaces. You will have two big challenges in this scenario:
- Sling request handling - Sling uses the extension to map a request to script. By default sling would consider .shtml to be different than .html and you'd need to name your JSPs appropariately. This could be problematic if you are reusing components across both page types. I have never tried this, but you could consider using the Sling Default Get servlet's alias configuration to map .shtml to .html which might work, but I have never actually done that.
In the past when I have needed to leverage SSIs through CQ I have just configured Apache to do do the SSI processing on .html to avoid these challenges. It means a heavier load on the web tier and it has some potential issues but generally is a better option than trying to get CQ to handle the .shtml extension.
Also the other thing to consider is whether or not you really need .shtml files since CQ is pretty dynamic - usually you can figure out how to handle the dynamic assembly in CQ and not at the web tier (or using AJAX).
Or did I misunderstand your plan - are you managing these as files in the DAM. If you are managing them as files in the DAM then you just have to make sure that you have a rendering servlet that will set the right mimetype.
Thanks for your reply Orotas.This helps.
I do not want Apache to do SSI processing on all HTML as this would impact performance and the load time of page (as also mentioned by you).