Crate table_editor

Expand description

A browser-based editor for a repository’s JSONL tables.

A repository describes its tables by implementing TableLogic once per table—parse, serialize, validate, derive, siblings, and a column Schema—and App once for the collection. Server turns that into a local HTTP server: it serves the embedded browser bundle at / and the editor’s API under /api.

The API is GET /api/app for the shell (the app’s name and its tables) and three endpoints per table: GET /api/<table> reads, PUT /api/<table> writes, and POST /api/<table>/derive validates and derives without writing. A view is GET /api/views/<view>, and what one of its buttons writes is POST /api/views/<view>/actions/<name>. GET /api/health and POST /api/shutdown control the process. All file I/O runs here, through the Context that resolves the Data/ directory; the browser is a thin UI that renders whatever the schema in the GET payload describes.

Launching reuses an already-running server on the same port (it just opens a browser at it); --restart shuts the old one down first and starts fresh. The server itself runs as a detached worker process, marked by an environment variable so it serves rather than re-spawning itself.

§Features

server is on by default and is everything above. Without it the crate is the file format alone—jsonl, ParseError, ValidationError, and ApiError—and depends on nothing but serde and serde_json, which is what a crate that only reads and writes the tables wants.

Modules§

jsonl: Reading and writing the one-row-per-line JSON the tables are stored as.

Structs§

ApiError: A failure with the HTTP status to report it under. Body and parse problems are 400; a write that does not come from a page this server served is 403 or 415; an endpoint or an action nobody offers is 404; an endpoint reached by the wrong method is 405; a body past the size cap is 413; and filesystem and serialization failures are 500.
Button: Something a row offers: a page to open, a form to fill in, or a reason it cannot be done yet.
Card: One thing, as a card says it: how it stands, what it is called, a few facts about it, and where to read more.
CardGroup: A run of cards under a heading, with the count of them.
Column: One column of a table.
Context: The Data/ directory a request’s tables live in. Sibling reads go through it too, so a table that cross-checks against another reads it from the same place the editor writes it.
Detail: One thing in full: a header saying what it is and how it stands, and sections of rows around it.
DetailRow: One row of a section: what it is, a few facts about it, and what can be done with it.
DetailSection: One run of rows under a heading, in one of the page’s two columns.
Field: One thing a form asks for.
Fields: What a form was filled in with.
Form: What a form asks for and what writes it.
FromRows: A completion list the browser builds from the rows on screen: trim each named field, drop the row when the first field is blank, join the non-blank ones with separator, then dedupe and sort.
MapSpec: The extra description a map column carries. A bundle renders one chip per entry as key: value, drops an entry whose value is cleared, and writes a map that empties as an absent field.
NewRow: How a new row starts: take defaults, then overwrite each field named in carry_forward with the value the last row that has one carries, so a run of rows sharing a genre or a publisher is typed once.
OptionsBy: A select whose options depend on another column: the browser looks the row’s value of field up in options. A value with no entry offers no choices.
Param: One control at the top of a view.
ParseError: A line of a JSONL file that does not deserialize into its row type.
Schema: One table’s presentation: the columns, how a new row starts, and any completion lists the columns draw on.
Section: One run of rows under a heading of its own.
SelectOption: One choice in a select. label is what the browser shows when it differs from the stored value.
Server: The editor’s HTTP server, configured for one repository.
ServerArgs: The arguments the editor’s subcommand takes. A repository whose subcommand takes arguments of its own flattens this into its own Args struct.
Speak: Where a cell’s play button sends its value. A bundle substitutes the URL-encoded cell value for {value}, and lets a localStorage entry under storage_key override the origin.
Status: A word for how a thing stands, and how that word reads.
ValidationError: A problem with one row of a table. field names the column at fault when the check is specific to one, and is null for a whole-row check.
ViewArgs: What a view was asked for.
ViewData: What one render of a view produced: a note about the whole of it, and the body it is to be read as.
ViewLink: A link to another of this app’s views, asked a particular question.

Enums§

ChipContent: What a map’s chips put before the value: the key’s label, or the key itself.
ColumnType: How the browser renders and edits one column.
Datalist: A completion list a column’s input draws on, in one of two forms: a fixed list the server computed, or one the browser computes live from the rows on screen.
Front: Where the editor opens when the address names nothing.
ServerCommand
Tone: How a status reads, from the five the bundle draws.

Traits§

App: One repository’s editor: a name for the shell, the tables it serves, and the views it computes.
Table: The object-safe façade the router holds. Each method returns the JSON body of one endpoint.
TableLogic: One table’s per-repository logic.
View: The object-safe façade the router dispatches through, as crate::Table is for tables. A blanket implementation covers every ViewLogic, so nothing outside this module implements it.
ViewLogic: One repository’s view.

Functions§

probe: Ask a server on 127.0.0.1:port for path, returning its status code and body.
probe_status: The status code alone, for a caller that only wants to know whether a service is up and answering. None and 0 mean what they mean in probe.