Models and slots

A model is a reusable layout. Its blocks live in BSPK_WEB_TEMPLATE, not in BSPK_WEB_CONTENT. Placing one on a page costs a single block of type model: the page does not copy the model's blocks, it points at them.

That is the whole benefit and the whole constraint: change the model, and every placement changes with it. What a placement may override is exactly what the model exposes.

Two kinds of slots

Kind	What it opens	Declared by
Zone	A region of the model that a placement fills with its own blocks	`vt_SlotName` on the model's block
Value	One property of one block, editable per placement	`vo_SlotExpose` on that block

A zone has a name, and it is referred to by that name, never by a uuid: reworking the model must not lose what placements have put in it.

Value slots: the naming rule

"vo_SlotExpose": { "vt_FieldLabel": true }

It is a flag, nothing more. A slot is identified by the block and the property, never by an invented name. The placement stores its own value under:

vo_SlotValues["<block uuid>|<property>"]

The same idea comes in three variants:

Exposure	Placement stores under
`vo_SlotExpose` — a property	`<uuid>\|<property>`
`vo_SlotCssExpose` — a style path (`target\|breakpoint\|variant\|property`)	`<uuid>\|css\|<that path>`
`vo_SlotEventExpose` — an event type	`vo_SlotEvents`

vo_SlotLabels holds the label shown for a slot, indexed by slot name. When it is empty, the name itself is displayed.

Events add up, they do not override

Exposing an event type does not give a placement the right to modify the model's event: that one stays read-only, always. It gives the right to add one of the same type, which runs in addition.

The switch is still required, even though it protects nothing against overwriting: it defines a surface. Without it, any placement could hang any behaviour on any block, and the model would guarantee nothing.

What cannot be exposed

The content of a text block cannot be exposed. It is a self-contained widget with its own editor, and it has no property to hand over.

Editing a model: a third context

Neither a page nor an admin template: the blocks of the open model.

GG_IS_MODEL_EDITOR says the editor is open;
GG_EDIT_CONTEXT names the table being written to;
GG_IN_MODEL_RENDER says a model is being rendered inside a page.

The model editor is the most demanding context to get right: no menu entry, no webDomainMenuUuid. Whatever works there works everywhere, which makes it the right place to test a mechanism.

Its descendants are fetched the same way as anywhere else:

query("uuidKey = :1 or parentCollection % :2"; root; root)