Page families and content types
页面家族与内容类型
A content type is a structural contract, defined once in code. A page family is one recurring editorial purpose in a site, reusing a type and adding route, labels and editorial policy. Together they draw the boundary of what AIBlog manages.
Concepts
AIBlog manages recurring editorial pages, not arbitrary layouts. Two ideas carry that boundary: content types and page families.
Content types
A content type is a structural contract. It says which fields a page has, whether the page carries a body of blocks, and which block kinds that body may use. Two types ship with the package.
- article: a bilingual apparatus of title, standfirst and kicker over a body written in the source language, with an optional cover and a closing gallery for photos the body did not place
- profile: a fully bilingual fixed-field page with a repeatable journey of steps, each with its own photos, plus an endorsement and certificate numbers
A type is defined once, in code. From that one definition the package derives the validator, the structure section of the composer's prompt, the editor's field kinds and the renderer's markup. They cannot drift apart because there is nothing to drift.
Page families
A page family is one recurring editorial purpose in a site: news, columns, event reports, documentation, showcase. A family reuses a content type and adds what the type does not know.
- the route and the archive route
- a label in each locale
- an editorial policy: the purpose in a sentence or two, which block kinds are allowed, which fields are required to publish, whether the source's chronology must be kept, whether quotes may only be verbatim spans of the source
- listing order, by date or by sequence
- a presentation variant, which surfaces in the DOM as a modifier class so a theme can style news and columns differently
Several families may share one type. The same source material composes differently as news, as a reflective column or as an event report, because each family's policy goes into the composer's cached prompt.
Why not pages and templates
A page builder hands the client the layout and hopes they use it well. A family hands the client a purpose and keeps the layout. The client never chooses block types, columns or widgets. They paste text, drop photos, and say what they want changed in plain language. The composer proposes blocks within the family's vocabulary, the validator refuses anything outside it, and the site renders what survives.