Bottom Line question: How can we manage same Component Presentation (which is statically on a Page) appear in multiple places on various pages without having to write logic in the PT.

Situation: Publication "Pub" will always publish XML files with Pages having static CPs in it. "Pub" has 3 SG's and each SG's Pages are consumed by 3 different Java based platforms. SG names: SG1, SG2 and SG3.

Important part: The page layout is controlled by these Java platforms. They have slot numbers for every CP to determine where it is placed on a Page. So the idea is to have "associate" a slot number to a CP and publish the Page, so the Java platforms understand where to render the CP.

FYI - Position of CP on a page is immaterial as I mentioned that page payout is controlled by these Java platforms.

Work done till now: 1. Built an Anguilla UI extension to have a new tab for every CP on the right side which would take a slot id as an input.


  1. How can we save the slot id on a page save and retrieve it when the page is opened? Can a data extender help in this case and how? Or would ECL would be the right way?

  2. Another idea is to create a page metadata field which will store delimited slot Id and CP Id (Comp and CT id) info. And have validations that a user shouldn't be able to change change that field manually. (This to me seems a work around, if there is no way to do point 1)

Wish I could : Explain Java platforms/businesses - How Tridion works and try to manage the page layout in Tridion :)

2 Answers 2


Interestingly enough, what you would require here is: "Component Presentation Metadata", which, unfortunately, doesn't exist with Tridion. So you need to get inventive.

There are, as you already mentioned, several ways of compensating for it:

  1. Use PageMetadata to store the information you need: advantage is that you are using OOTB Tridion functionality; disadvantage: is clumsy to use and it's not directly matched with the CP itself;
  2. Use Custom GUI extension: the path you already took, maybe combine it with saving the information you need as Application Data on the Page itself. Read/Write this appdata as you need to store that info or to use it when rendering the page in template code;
  3. Mis-use Target Groups (which are associated with each CP on a Page) and specify for each Page a different 'Target Group', which would represent the meta information you need;

There is no silver bullet, unfortunately. See what choice appeals most to you / your design / your requirements. #2 sounds pretty good to me.

  • Yes I like the second option too. Capturing the info as a part of App Data here sounds as an appropriate option. Thanks for sharing Mihai Commented Feb 13, 2014 at 20:47

This scenario sounds a bit like the Regions concept, where Component Presentations on a page should be rendered in different areas (typically a main content area in the middle containing an article, or a set of article summaries, and then one or more secondary regions containing supporting items like widgets or banners).

I have seen the allotment of Component Presentations into regions determined by component schema, or template or a combination of the two. A recent project I worked on used the Component Template title, so you had titles like Full Article [Main], Banner [Sidebar], Banner [Header] etc. mapping to regions Main, Sidebar and Header.

So you could having a copy of your Component Template for every slot that it could be used in, to achieve your goal - modular templates make it very easy to duplicate templates without duplicating processing or layout code.

Whether this is a workable solution depends on how many slots there are and perhaps other details of how the slot system needs to work, your description is a bit too abstract to tell for sure.

  • Thanks for additional options Will. Yes I kept my question abstract to get high level approaches/thoughts. I understood your response and it'll work although it duplicates content/code. As alternatives we can attach a CP list to page meta config component or have a metadata to a CT. I'll give a shot to the App Data approach Mihai suggested first as it sounds cleaner. Commented Feb 13, 2014 at 21:00

Your Answer

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

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