App Bar
The document bar under the platform header in every tool shell: what you are working on, the controls that app needs, whether it is saved, and what you can do to it.
When to Use
Use when:
A page holds one document the reader is working on: an agenda, a live session, a synthesis. The bar names that document and carries the actions that act on it.
Don't use when:
The page is a list, a landing page, or anything without a single subject.
ws_header() alone is the whole chrome there.
States
One anatomy, four apps. The title, save state, and action cluster are constant; the centre is what changes. Pass 'state' to get an app's centre and default actions without spelling them out.
Strategize
Nothing in the centre. The work is the page, not the bar.
Plan
Reads out the shape of the workshop being built: duration, date, start time. Values come from 'context'.
Facilitate
The two things you reach for in the room: start the session, show the join code.
Synthesize
Switches between the two readings of a finished session. The trailing action is Share rather than Continue, because synthesis ends in something you send.
Usage
<?= ws_app_bar([
'state' => 'plan',
'title' => ['mode' => 'editable', 'text' => 'Untitled workshop'],
'context' => ['duration' => '120 min', 'date' => '2026-08-15', 'time' => '09:00'],
'saveState' => ['text' => 'Saved', 'state' => 'saved', 'hidden' => false],
]) ?>
A named state fills only what you leave empty.
Pass your own
'center' or 'actions' and they are kept exactly as passed. The state never overwrites a caller.
An inferred state adds a class, not content.
With no
'state', the bar reads the shell's ?view= and adds .ws-app-bar--{state} for styling. It does not inject a centre: the apps already pass their own, and a bar should never grow controls its page has no code behind.