Modeling and Generating the Admin
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.
An administration application should reflect the application being managed. Acme Catalogue needs Products, Categories and Enquiries, with relationships and business rules that editors can understand.
The proposed modeling interface creates a versionable declarative model. It describes a Product's name, stable identity, category relationship, image reference and publication fields. The framework uses that model to generate the conventional administration surfaces.
From a model to a working module
The model defines structure and constraints. Admin contributions describe how people interact with that structure: visible list columns, supported filters, appropriate field editors and available operations.
| Model or behavior | Proposed admin result |
|---|---|
| Product name with a required constraint | Labeled editor, validation feedback and selectable list column |
| Category relationship | Relationship selector with suitable permissions and lookup behavior |
| Image reference supplied by a media extension | Media picker and preview from that extension |
| Enquiry with workflow actions | List and detail views plus explicit domain operations |
| Localized content, when configured | Locale-aware editing with clear publication state |
Generation provides the conventional infrastructure. A team still defines its business behavior. “Approve enquiry” is an application operation with preconditions and effects; generating a form does not establish those semantics.
Modeling is itself a controlled change
Adding a field in the model designer edits a model document in the selected workspace. Validation and generation produce a change that can be inspected. Applying a corresponding schema migration is a separate lifecycle step.
This differs from editing a Product record. Changing its description updates content through the module's declared storage and publication rules. Adding a required field changes the definition used by many records.
The UI needs to distinguish these scopes. A production content editor should not accidentally change the application schema while editing a title.
Extending the generated application
Extensions may provide field types, specialized editors, list layouts, filters, panels and whole modules. A Product can reuse a media type's editor. A Lab service type can contribute a configuration form. A composite module can present related child modules without copying their internal implementations.
Generated files and user-owned customizations have distinct ownership. Rebuilding must preserve custom actions and renderer contributions. If a model change breaks a customization contract, diagnostics must identify the affected extension point.
Code defaults and editable configuration
C# declares defaults, constraints and which settings can be changed through the UI. The UI edits versioned configuration within those constraints. A deployment operation may offer additional choices only where the policy permits them.
An administrator can see the effective value and its origin: default, saved instance configuration or permitted operation choice. This avoids a setting that appears saved but is silently ignored by a code constraint.
The admin has its own extensibility
The admin is not tied to one universal form renderer. A module can select an installed editor family with the required capabilities. Accessibility, validation, localization and navigation remain part of the contract between a host and a contributed editor.
The admin specification defines those interactions. Modeling and generation defines the source and customization boundaries.
Previous: Building and Editing the Front · Next: The Integrated Lab · Series index · Section index