Rendering content types

Outputs

An output is a serialization of the content, not a file extension. One type may declare many; today the common ones are:

• html — the public document output. Declaring it is what makes a type's assets pages.
• fragment — the type renders as an embeddable band through a partial (this is also what makes a type insertable as a section).
• json — structured delivery of the content bag.

The HTML output, outside-in

A page renders through a chain the output owns, chosen outside-in:

document template (the shell)
  └─ Content renderer:  None | Layout | Partial
       └─ the asset's fields / authored body

1. Template — the document shell. The chooser lists the whole Templates surface; picking one is what makes it the document. A template with a data-accent-content region receives the page body inside it; without one it renders as-is (static output). Nothing warns and nothing blocks.
2. Content renderer — what fills the shell's content slot:
   • None — no intermediary; the authored page body fills the slot as-is.
   • Layout — a visually composed body arrangement (bands, regions, a Page-content band), built in the Layouts admin. This is the multi-zone surface: when a page needs several editable areas arranged around the body, the answer is a Layout — never a template with multiple regions.
   • Partial — a data page: the type's fields render through one EJS partial; the body is locked to the fields.
3. Resolution follows the assignment: whatever you bound is what renders. The default shell is only a fallback for pages with no binding anywhere.

Delegation: the type may hand the shell to its pages

If a content type's HTML output binds no template, each page of that type chooses its own shell: the page configure panel grows a Template picker (same chooser, same no-slot warning). The effective shell is:

type's template  ??  page's own template  ??  default shell

Binding a template on the type hides — and stops honoring — the page-level choice; there is no per-page override of a bound type.

This is the import pattern: bring N static templates in, make one type with no template bound, and each page picks its import. Slot-less templates render as-is, so a scraped site becomes: one type, N pages, N templates.

Where you set all this

On the content type (Manage Site → Content Types → the type → Outputs): the template select, then the Content renderer radio. On the page (only when the type abstains): the configure panel's Template picker. The document map shows the result — template-shell pages root their body under a Page content — Template header, the same reading a layout page gives.

Deep records

The content model — design record — rev 4 ("the template inversion: views choose outside-in"), the Content renderer naming, the warn-don't-block binding amendment, and delegation, in order.