A dashboard that does something.
Most dashboards are read-only by construction: they show you a number and leave you to go somewhere else to act on it. A dash-b tile can carry a button, and pressing it writes a row, updates one, or opens a form built from your own table.
Two tiles
A button, or a form
Action
One button with a label you choose. It runs a single named operation against one of your own tables — mark today's takings banked, add a shift, close a ticket. Nothing to type, one press.
Data form
The same thing when the operation needs details. The fields are drawn from the table's own schema rather than from anything the design declares, so a column you rename changes the form and a column you delete stops being asked for.
What an action is
Three keys, and no fourth
An action names an operation, names what it operates on, and passes parameters. That is the whole vocabulary:
- The command is an index into a registry that only dash-b's own code can add to. A design cannot invent one.
- The binding is a name, resolved when the button is pressed against the documents your account holds. A design somebody sends you that names a table you do not have stops and says so.
- The parameters are a literal, or one named value read from the form, the tile or the press. One level deep, and nothing else.
A URL, a header, a token or a role written into an action is a dead key.
Nothing in dash-b reads them. A test dispatches an action carrying all four and checks that none of them reached the handler.
The vocabulary is deliberately weak. Every operator that gets added to a parameter language is a step toward a rules engine living inside a file that strangers send each other, and a design file is not a place to run somebody else's logic.
The rules a write obeys
Three of these are inversions of how the rest of dash-b behaves
An unknown command is a loud error
Everywhere else an unrecognised key is ignored quietly, because a design should survive meeting a newer version of itself. Not here: a write that silently does nothing looks exactly like one that worked.
Only a real press counts
Whether a person actually pressed the button is decided by the runtime, never by the design. A design that claims a gesture happened is refused.
Anything that changes data confirms
Operations are read-only, local, or changing. A changing one asks first — and cannot opt out of asking — and is given a key that makes a double press land once.
Where it does not appear
Not in an exported HTML page
Export a design as a standalone page and the buttons are not in it. An export runs none of dash-b's code, so a form there would collect somebody's typing and have nowhere to send it — which is worse than not offering it at all. The tile is a designer and account feature, and the export says so by leaving it out.
The same goes for a published link. What a reader can see, and what they cannot, is decided by whose data the tile is bound to — how sharing works sets out both cases.
It needs a table to write to.
That can be a table on your account, or your own database reached through a connector you host — in which case no database password ever reaches us.