Building and Editing the Front📋

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.

A site builder should be able to work on the page people will see. In an authorized workspace, the proposed front editor reveals the current page structure, makes editable regions visible and offers contributions from installed extensions.

For Acme Catalogue, the builder opens the product listing, adds a category navigation component and places product cards in the central area. Each product page uses a shared detail view bound to the current Product record.

Editing in context📋

The composition interface exposes the page, its reusable view and layout, their areas, the zones within those areas and the widgets inside the zones. A user can create a manual page, add or reorder a zone, move a widget and configure its input without guessing which file or database record controls the result.

Before changing a shared view, the editor identifies its scope: “Product detail view — used by product pages.” A change to one Product's description remains a content change; replacing the product detail layout is a composition change with a broader effect.

Saving a valid composition change updates the workspace preview. A Git commit records chosen workspace changes later. Publishing content and activating a production release are separate actions.

Choose delivery for the site's needs📋

The model of a Product does not need to change merely because the delivery adapter changes. Its visual implementation may: a C#/Blazor component and a Hugo template are different rendering contributions.

A static catalogue can include an enquiry form whose submission uses a dynamic endpoint. The editor must identify that dependency. It cannot treat a server-only operation as if it were implemented by static HTML.

Useful composition beyond widgets📋

A package may supply a navigation system, page type, search experience, form workflow or complete frontend application area. Widgets are one contribution family. Other extension points should expose their own constraints and configuration through the same discoverable catalogues.

Nested components use declared slots or child contracts. For example, a Product Card can accept a media component from a separate extension. The parent must state which child types its renderer supports.

Public pages and discoverability📋

Public routes need stable links, canonical URLs, localized metadata where supported and sitemap entries. Admin and development routes follow their own exposure policy. Giving a branch a hostname does not automatically make it part of the public sitemap.

A path prefix such as /diem affects links, assets and generated canonical URLs as well as route matching. The same address-binding model must reach the renderer and its assets.

Feedback when a combination cannot work📋

The editor should explain an unsupported combination before publication: for example, a widget requiring an authenticated server circuit placed in a static-only target. It should point to the component and missing capability, preserve the user's work and offer compatible configured targets.

The front specification defines composition operations. The renderer architecture explains capability negotiation and static export.

Previous: Vision and Diem Heritage · Next: Modeling and Generating the Admin · Series index · Section index