views
A view is a named SELECT of its table — it lives inside the table, in tables.<t>.views, and decides WHAT and HOW is read: columns, filters, order, page size, display formats. It carries no idea of where it is shown: public routes and admin menu items bind views to pages by name. The same view executes for whoever the entry point admits — a view bound in the admin menu is refused on a public route by the engine itself.
| key | description |
|---|---|
| select | column list; include the id column if the view is a paginated list |
| fixed_filter | WHERE conditions baked into the config (string/int/bool values). This documentation uses published=1 |
| filter_by | columns filterable from the URL — path parameters and the query string, several at once (combined with AND, equality only); each column needs index:true or type id. The group pages of this site filter articles by the indexed grp column |
| order | list of {col, dir asc|desc}; for list views order[0] must be the id column; default is id DESC (newest first) |
| limit | present (1..1000) — a list with cursor pagination (?cursor=..., next_cursor in the template context); absent — a single row, and all filter_by become required |
| formats | display masks for select columns — dates and numbers rendered human-readable on pages; see formats. The JSON API is not affected: it always returns raw values |
The view rendering this documentation (inside tables.docs.views):
"doc_list": {
"select": ["id", "grp", "title", "descr"],
"fixed_filter": { "published": 1 },
"filter_by": ["grp"],
"order": [{ "col": "id", "dir": "asc" }],
"limit": 50
}View names are global across all tables — a route says just "view": "doc_list".