Front: Pages, Areas, Zones and Widgets📋

Status: Public design proposal and product vision. This series presents Diem CMF .NET’s intended architecture and capabilities. Proposed features remain subject to implementation and validation; existing components are identified separately.

The frontend contract must support reusable composition, in-context editing and multiple rendering targets. It preserves the useful distinctions established by the original Diem schema↗ (ouvre dans une nouvelle fenêtre) while defining new .NET contracts independently.

Composition concepts📋

“Widget” identifies one frontend contribution family. Packages may also provide page types, forms, navigation, applications or additional families with their own contracts.

Shared view edits must indicate affected page scope. Page metadata and record content edits must remain distinguishable from shared composition changes.

Editing operations📋

The authorized editor must support manual page creation, selecting a view/layout, adding and removing zones, moving and ordering components, editing configuration and previewing the result.

Copy/cut/paste operations must preserve or deliberately remap component identity and references. Moving a component must validate its destination constraints. Removing a zone must show the affected contained components.

Invalid edits must return diagnostics without claiming successful rendering. Concurrent edits must detect a stale composition revision rather than silently overwrite another author's saved structure.

Nested contributions📋

A component can expose typed slots or child contracts. Product Card may accept an image renderer supplied by Media and a call-to-action supplied by Enquiries.

The parent declares permitted child capabilities. The renderer checks the whole composed structure, including nested children. A missing nested renderer is a compatibility error at the component that requires it.

Recursive domain types and recursive component structures are separate concerns. The renderer must validate the actual instance tree and prevent accidental infinite expansion.

Renderer contract📋

Each renderer must declare supported contribution types and required execution capabilities. It receives the effective domain binding, composition revision and authorized data/content context.

A static adapter uses recorded snapshots and emits the required source/assets before invoking its generator. A dynamic adapter supplies runtime rendering and application-service integration. An interactive component on a static page declares its endpoint or client runtime dependency explicitly.

Renderer output must preserve route identity, metadata, accessibility contracts, asset references and base-path behavior. A missing capability must be reported before public activation.

SEO and publication📋

Public pages can contribute canonical URLs, titles, descriptions, locale links and sitemap entries according to their configured publication and indexability. Draft content, restricted routes and development previews must follow their own policies.

This publication state concerns application content. The present documentation itself is public and labeled as a design proposal.

A new static publication requires a new output built from the selected snapshot. A dynamic publication may update served content through its declared cache and publication process. Neither implies a source-code commit.

Acceptance📋

FRONT-01: create a page and manipulate zones and nested components in context with a visible shared-view scope.

FRONT-02: render the catalogue through Hugo and the dynamic adapter using declared compatible contributions.

FRONT-03: reject an unsupported nested component and retain the editable configuration.

FRONT-04: public metadata and assets respect the binding's path prefix and publication policy.

Previous: Modeling and Module Generation · Next: Admin Modules and Pluggable Types · Series index · Section index