[Page] cq:designPath property not honored

[henrykuijpers]

When setting the cq:designPath property on a page, it seems to not be reflected actually.

I would expect the selected design to influence the look and feel of the page, i.e. take over my body { background-color: black; } styling, or actually show the alert I define in the JS with alert('This is my specific brand A design on the generic template');.

However, it does not. The "getDesignPath()" method is, as far as I can tell, only used in the /apps/core/wcm/components/page/v2/page/head.html, where it is passed to the template defined in /apps/core/wcm/components/page/v2/page/headlibs.html.

There are 2 problems:

• The designPath is not actually used in that file, which explains why the page property is not working
• The designPath is actually only the design path, so it could never be used to load the styling and/or scripts

[gabrielwalt]

The cq:designPath concept is tied to static templates, but as Core Components don't support them, we should instead make sure that this code doesn't get executed anymore (typically within head.html and headlibs.html). With editable templates, we instead want to use the page policy to configure template-specific client libraries. I'd be curious if there are use-cases that aren't covered by this policy mechanism, but that were possible with cq:designPath.

[henrykuijpers]

If it is truely the case that cq:designPath is purely intended for static templates, then yes, there are some use-cases I can think of that are not covered:

One set of templates, that is used by multiple websites that each have their own styling. If cq:designPath (or an alternative) cannot be used, then to me it seems to be impossible for those websites to reuse the templates, if the styling is defined in the template, instead of in the website-context. Do you see a solution for this scenario with the current core components, @gabrielwalt ?

Specifying a page policy works for that page specifically. It doesn't work for an entire site, right? Or one would have to specify that policy on each and every page in the website. That doesn't seem to me as the correct way forward?

Or, are editable templates not intended to be reused accross multiple websites? I.e. them being a sort of whitelabel website, until different styling is applied by a specific brand/website?

[gabrielwalt]

Thanks for the details, @henrykuijpers, the use-case you described makes sense and is indeed not possible yet with editable templates. However, I see two issues with cq:designPath: first, for performance reasons, we don't want to execute the old design logic, and, second, architecturally, we want to move away from /etc/* folders. Therefore, I'd rather be for searching for a different solution to this use-case.

Would it be possible for you to set a clientlib property on the site root page, and to implement a custom model to retrieve that property from your customheaderlibs.html?

One slight correction to what you wrote: the page policy works at a template level, so there's no need to set it on each page, but you need to define it on each template that's used by the site.

[henrykuijpers]

Hi,

I understand that it is not the intention to work further on the old design logic. However, the page property is there. Shouldn't it be removed then?

With regards to the /etc part - nowadays, design libs can live under /libs/settings/wcm/designs and /apps/settings/wcm/designs as well. So, stepping away from /etc is still possible.

You're asking if it's possible to specify a page property on the root site, where I can enter a category for the design. That's possible. Was your intention to use inherited page properties to determine the clientlib to load? What about context aware configuration? I believe the inherited page properties way of working is considered the old way, now that we have content policies, caconfig, ...?

What about being able to configure content policies based on the context? (I.e. the core components starting to leverage caconfig.)

There could be various locations to enter settings or content:

• OSGi (instance wide)
• OSGi (per resource type or similar)
• Template type level
• Template level
• Per component using design dialog
• Per component instance using normal dialog

This tackles a lot of use-cases. When adding the additional layer of configuration (caconfig), we could tackle even more use-cases.

One slight correction to what you wrote: the page policy works at a template level, so there's no need to set it on each page, but you need to define it on each template that's used by the site.

Yes, I understand. But when I configure the page policy at the template level, I still have my 5 brand pages that are using the same exact template, but do need to load a different (or additional) clientlib. I don't want to go to every page inside a brand and then manually define that page policy. Especially when the pages are in a blueprint this becomes unmaintainable.