Duplicate or "split" (Mix-and-match) XPM Regions

Question

How would you recommend implementing XPM page regions that could accept the same Allowed Component Presentations (Schema and Component Template [CT] combinations), possibly with different quantity limits?

For example, "[content]" might accept Components based on Article Schema with matching Article CTs. Imagine the following regions in different arrangements:

• [banner, qty: 1 allowing image or video with matching CT]
• [content, max: 3, allowing articles, blogs, etc. with matching CTs]
• [promos, 0-3, allowing promos with promo CT]
• [content, max: 1, allowing articles, blogs, etc. with matching CTs] (again)
• [footer promos, allowing promos with footer promo CT]

I've explained the relationship between Insert and Regions and follow Will Price's thoughts on regions in this answer. We can use the following the drive Component Presentation placement into regions:

• Schemas
• Templates
• Combination of the above ("Allowed Component Presentations")

Will's example includes "titles like Full Article [Main], Banner [Sidebar], Banner [Header] etc. mapping to regions Main, Sidebar and Header."

I'm thinking our options for a "mix-and-match" region approach are:

1. Different Component Templates, one per Region.
   • Pros: CTs can re-use same TBBs as copies of each other, with different names.
     • Article 1
     • Article 2 (though the name feels somewhat hackish)
   • Cons: Duplicate CTs and options limited by number of pre-configured CTs. What happens when we want a 3rd or 4th region? More CTs?
2. Nested Regions?
   • Pros: Single [content] XPM Region, which may include other regions
   • Cons: Has anyone implemented this? I've noticed an XPM region recognizes all CPs within it, which means this example [content] region needs to also allow promos and footer promos. I've also seen XPM recognize ST regions within XPM regions in the breadcrumb (not sure on regions "within" CPs, though).
3. Near-duplicate [content] regions, with Page Template logic that "splits" which items go where, possibly based on region quantities.

So a Page Template could place the first 3 Articles in the first [content] region and any additional in the second. The Page's Component Presentations grouping wouldn't matter, just order. DWT would have have separate TemplateBeginRepeat loops that relied on these quantities.

This assumes this regions are somehow configurable in Tridion fields (in CPs, Page Metadata, or Template Metadata), rather than hardcoded in layout TBBs.

XPM authoring expectation or use case:

• Place certain CPs (e.g. Article with Article Summary CT) in multiple parts of page using drag-and-drop
• Insert button might not work
• The CTs may actually differ, but the Schemas should be the same (as a user, I shouldn't have to recreate a Component to place it somewhere else)

Answer 1

Since XPM regions only accept and restrict how content is added to a page's Component Presentation, we need additional logic or "attributes" to implement "duplicate" regions (thanks to Mihai Cădariu for the insight).

For each reason, the Page Template needs to loop on Components or an array of matching item. For example:

<!-- TemplateBeginRepeat name="Components" -->

Or:

<!-- TemplateBeginRepeat name="Content-Region1" -->

<!-- TemplateBeginRepeat name="Content-Region2" -->

Where Content-Region1 and 2 are Component Presentation (CP) arrays, split according to this additional logic*.

If not creating a specific array in the package for that region, additional checks for Component Template, Schema, or other item-specific details are needed:

<!-- TemplateBeginIf cond="ComponentTemplate.Name = '...'" -->

*To make the distinction between the CPs, we can use anything we can determine in code. Since XPM regions include Schema and Component Template, this has to be about the Components themselves:

• Metadata
• (Virtual) Folder location
• Naming convention (possible, but probably not the best approach)
• Etc.

If the near-duplicate regions have limits, then quantities could indeed be used.

The XPM behavior would then be:

• When a user drags a Component into a region that allows it, Page Template logic will inspect the Component (and maybe quantities) to place it in the correct location in the rendered page.
• The CP may actually appear in a different XPM region, based on the PT logic
• XPM will independently confirm or detect if the CPs in the region match the region rules

For the last two points, it's probably a good idea to have PT layout logic match XPM region settings.

Edit: The Documentation actually recommends against this approach with: "...a specific combination of schema and template values can occur only in one region." So consider this a way to abuse XPM regions and only adopt if it's a good fit for your content model.