Creating pages versus component-only approach

Question

The 'normal' way to publish pages to your webapplication is to create a page, add component presentations to it and publish it.

In several implementations I see this approach combined with a 'component-only' approach, where a component is published (without a page) and the webapplication renders it as a page. Example: vacancies are created in Tridion via a (Core Service) middleware, which is called by external Recruitment software. The vacancies are (un)published automatically, no pages are involved.

I am wondering what your opinion is about the future of the component-only approach and the 'page' approach and in with situation you definitely should (NOT) choose for the one or the other approach.

Answer 1

Using pages is ideal when there are lots of different pieces of content that need to appear on a single webpage. For example, a banner carousel at the top, some 'article' content, some promos, a form, etc. Having lots of content on the webpage like this would be difficult to scale and for editors to understand what content will appear where using a component-based approach (with lots of application logic).

Using a component-based approach is great for dynamic content, where, for example, there is lots of similar content (e.g. news articles, events, job listings, etc.) that need to be rendered together and either sorted (e.g. chronologically) or filtered (e.g. show me only jobs in the Netherlands).

A component based approach can also be useful when only snippets of content are to be used on certain pages. For example, I recently worked on a project where the 'My account' section of the site was a separate (.Net) web application that only displayed small 'promo' content that were published from within the CMS.

My advice would be to stick with using pages where possible, as these are easier for editors to understand. They also allow CMS functionality such as 'View on Site' to work (without any customisation) and for the site hierarchy to be managed using the containing structure groups.

Answer 2

First, I highly recommend Will Price's excellent post on "DCP Ettiqutte:" http://www.tridiondeveloper.com/dcp-etiquette-why-would-you-make-a-component-template-dynamic

Let me also add that there are actually three options with pages and "dynamic" content:

3 types

In my "Dynamic Vs. Static Component Presentations Vs..." post, I explained we have:

• (Page-less) Dynamic Component Presentations (DCPs)
• Pages with Embedded Component Presentations (commonly referred to as "static" component presentations [on a page])
• Pages with Embedded Component Presentations added dynamically

You don't need to choose only one or the other, but you could pick the content model that fits your needs. I like Will Price's advice to "Make it static, unless we come up with a good reason to make it dynamic."

DCPs

I recommend Dynamic Component Presentations (DCPs) for "libraries" of content with same structure and fields where:

• The content is used across multiple applications and channels
• Ability to retrieve independent pieces of content is important via delivery-side queries (e.g. Taxonomy or Criteria APIs and latest GraphQL capabilities)*
• That content might be used with various renderings (e.g. summary, full view, short link), but order and placement is not directly controlled by the editor
• There's a good amount of content, where editors might manage these from a large list (100s) of Components in the Content Manager such as:
  • Press releases over the years
  • Large gallery of images
  • Anything that isn't worth the hassle of maintaining a separate list linking to these Components

Schemas that tend to fit this model have clear names that have a tangible meaning to the business such as:

• Article, Blog Post, or News/Press Release
• Frequently Asked Question (FAQ)
• Product, Business Location, etc.

DCPs (as the only option for particular content) are a bad fit when:

• The content rendering and specific data shown is very much based on context such as location or ordering on a page, specific website, or channel
• Editors need to mix-and-match such content on a page, with a bit of variation between pages
• Your applications expect specific resources, configuration, or pieces of content (by name or location) to perhaps always be available. If you care where the content appears, then it helps to have the location in the form of a Tridion Sites page and its resolved location

The worse I've seen is when new "pages" meant application configuration to hard-code references to Tridion Content Manager (TCM) Uniform Resource Identifiers (URI) every time editors wanted to add a page. It's easier to just let the CMS and editors create and publish pages rather than trying to treat individual DCPs as pages.

Pages

Again, Pages could use embedded static Component Presentations as well as embedded Dynamic Component Presentations. See Will's post on when to choose one over the other. Here are some scenarios where pages with static embedded Component Presentations help or might be expected:

• Control over placement and grouping of items on a page (Regions and Component Templates)
• Experience Manager in-context editing (click on an item to change its info, replace content in the context of the site, and create new content from example Page Types and Content Types)
• Your downstream applications need a predictable piece of content (configuration) by URL

Pages could be a poor choice when you have very structured content with little variation in content placement (see my "pros" points for DCPs above) or where the content is the page.

---

*Note that "dynamic" behavior where content seems to change in an application doesn't necessarily imply Dynamic Component Presentations and Content Delivery-side logic. You could still publish all the content and metadata data needed and use client-side or application logic to show or hide the correct content.