First, I highly recommend Will Price's excellent post on "DCP Ettiqutte:"
Let me also add that there are actually three options with pages and "dynamic" content:
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."
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.
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.