nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Any cautionary tails about using the lscs document for .page

System

I noticed that the .page files are stored in lscs along with our dcr content. The xml for the .page file has pretty much everything I need in it and a lot more. The thought is to create a preController that will pull the juicy bits out and store them in the request for any of the components to use. The main use case for it will be so that any related content/menu components will know what dcr is being displayed by the center or main content component of the page. Anyone have a better idea or a stop dont do that?

Find more posts tagged with

Comments

Migrateduser

Well it worked fine but ultimately we have decided to set the metadata on the .page files instead of the dcrs. It solves several problems.

Murugan_P

Well it worked fine but ultimately we have decided to set the metadata on the .page files instead of the dcrs. It solves several problems.

Can you elaborate more on this. What metadata you set for the .page and the problems it solved ?

AlexC

As I posted in another thread, .page structure and content can and has changed even in patches and should not be assumed to be fixed and defined, it is an internal file so release docs will not note that the structure changed and you will have to adjust your code (when things break) on it if you decide to use it. There is no guarantee that the .page will stay XML either, it is intended to be an internal file.

Migrateduser

Can you elaborate more on this. What metadata you set for the .page and the problems it solved ?

We have changed our approach drastically, but what was solved is that if we set the ID of a datum to a know value then a pre-controller could get the .page file and put the value into the request so that other components on the page would have access to the same value. In this instance we had a "detail" component that displayed the content in the center of the page/content well. Our related content/menus need to display their various list of links based on what that component is displaying. So, it seemed we were able to use it to determine the main dcr for the page (the datum contained the path to a dcr).

In the end it was a failed approach and we have reversed an early project design decision. The original discussion was between either having pure dynamic .pages and set metadata on the DCR's or hybrid/static .page files and set the metadata on the .page files. Originaly, we went with the dynamic .page approach for the sole reason of not wanting to manage .page files when a template or component was changed. We would have thousands of .page files and this did not sit well with us.

After two - three months and constant issues, some one from the Klish group pointed out that in CCP there is a SitePublisher menu with a "Get Latest Components" menu option that would work on the whole site, would have been nice to know 2 months ago (yes it made me feel stupid and proved ignorance is not bliss). So now we are changing over to the static/hybrid .page approach.

This is getting to be a long post so I will end here. If any one cares about the pros and cons that we have run into with either approach just ask and I will brain dump those also. And, thanks to AlexC for the other .page info.