6

Imagine the following hierarchy of pages + structure groups (with the stated metadata field):

  • (StructureGroup): Section [MetadataField: BodyCssClass (text)]
    • (StructureGroup): About
    • (Page): Default
    • (StructureGroup): Contact
    • (Page): Default
    • (StructureGroup): Help
    • (Page): Default

All pages have the same page template which contains 'Add inherited metadata to page'.

In my page view I write

<body class="@(Page.MetadataFields["BodyCssClass"])">

I publish all 3x pages which each gather the structure group metadata field 'BodyCssClass' and become an instance, for each page, in the broker.

Therefore, the metadata value is duplicated for Nx pages under the structure group.

When the structure group field is changed the editor must republish all pages for the change to take effect other wise some pages end up with the old colour.

I just wondered if anyone faced the same scenario and if anyone could suggest a way to avoid the republish of all pages?

Note: The example here is to help explain the scenario, I'm interested in the actual scenario (the need to republish) rather than a solution for this example/
Note: Also, the editor can publish the structure group, so this isn't such a problem, I was just looking for a more elegant solution.

Thanks in advance

Improve this question

2 Answers 2

Reset to default
5

I guess you could be quite creative here and do it in many ways... here's one I think you can do relatively painlessly...

  1. Have a Component created automatically for each Structure Group that gets created
  2. Have a dynamic Component Template that renders the metadata for the structure group whenever the CP is published
  3. Move your page logic to inherit metadata to get it from the DCP in question at runtime (delivery) instead of Publish Time (CM)

There's a lot of scenarios to cater for to make this work, here's what I can think of:

  • The component should not have any content other than the link to the Structure Group. I would investigate some of the tricks that were built into Parameter schemas that allow you to link to Organizational Items - check the default parameter schemas, there's something about the way the external url fields are structured that allow you to store xlink:href references to organizational items and Content Porter understands those links.
  • When publishing a Structure Group you should ensure the correspondent CP gets published - a custom Structure Group and Publication resolver is probably your best option here.
  • The dynamic CT should just get the data from the correct structure group in the current context and push it out, nothing too fancy here
  • Pages should know which CP to get their content from. I would probably add logic to the page templates to calculate which CP to load when publishing, then add something along the lines of <tcdl:ComponentPresentation PageURI="%currentPage.Id%" ComponentURI="%SGComponent.Id%" TemplateURI="%SGComponentTemplate.Id%" />, and let Tridion Content Delivery then deal with the rest.

If the metadata you're inserting is inserted all in one location in the page, then the approach above would work. If instead, you use this data a bit all over the place in your page, then you're better off with having the CP output some sort of structure data (JSON or XML), then have controls/tags on your page to load the data and use it where appropriate.

Improve this answer
1
  • Thanks very much Nuno. I'm glad you suggested the usage of a dynamic component presentation as I was also thinking along these lines. I was pondering on how the page could know which DCP to load, I originally though of an event to add a unique value (text) in both the auto generated component and the page metadata so that a broker query could take place when rendering the page. I like your idea (calculating which cp to load when publishing) better as it adds a nice level of automation. Thanks again
    – Jonathan Primmer
    Jun 28, 2013 at 9:28
2

I have two suggestions.

Style In Tridion?

  • Keep the structure group references the same, but have the actual style definitions change.
  • Authors would select something (component link, .css as multimedia, etc) in Tridion and publish the change.
  • The css class stays the same and pages don't need to be republished.

The plus is easy configuration for essentially "page skins," but the catch is putting at least some CSS somewhere in Tridion.

As Part of Navigation?

  • Have the reference included as part of your navigation approach, possibly automatically.
  • Read your navigational structure (e.g. sitemap.xml, navigation.xml, etc) in your site to know what class to use.
  • Authors publish the overall structure, which controls navigation and includes this metadata.
  • Adjust as needed if using Taxonomy instead.

I'd also suggest a client-side approach (read the url, maybe?), but you would have to republish pages if the SG path changed.

Assumption: Though this is currently structure group (SG) metadata, specifically a CSS class, I see a one-to-one or maybe one-to-many relationship between the SG name (specifically, the SG's path) and some client-side functionality. Lots of ways forward from that perspective. :-)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.