4: The admin and API

With models and a menu declared, the CMS serves a full admin and a matching REST API.

4.1: URLs

List and record URIs come from each model's table name (or its uriList / uriRecord overrides), and the sidebar uri should match.

4.2: The write API

Every model is writable over POST, PUT, PATCH and DELETE, including nested child operations; reads are the rendered list and record pages. Writes are CSRF-protected, and the forms and the API share the validation defined by your schema.

4.3: Look and feel

The CMS ships themes and transitions as resources. An app picks defaults with prop theme and prop trans, and users can switch at runtime. Because the whole admin is generated, restyling is a theme choice, not a template rewrite.

4.4: Auth is optional

The CMS does not force authentication. The production Dashboard layers auth on top (login, roles, per-module permissions); a small internal tool, like the demo, can run open. Add the auth resource and gate routes when you need access control.

4.5: Dashboard widgets

The CMS home is not just a menu. Every model can pin widgets on it, so the dashboard opens as a live overview of the data behind it. A widget is a static objWidgets on the model, keyed by title, with a type and the data it plots:

static objWidgets => [
	'Articles' => obj (
		type: 'gauge',
		data: static::item(columns: 'COUNT(id)'),
	),
	'Price per plan' => obj (
		type: 'bar',
		data: static::pair(columns: 'name, price', order: 'price ASC'),
	),
]

Widget types: bar, gauge, line, list and pie. List the ones you use in resources (widgets/bar, ...) and add chart.js for the chart types. An order: key sorts widgets across models.