Additional info for a Component Presentation for controlling a Page layout outside Tridion

Question

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.

Questions:

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 :)

Answer 1

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.

Answer 2

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.