Adopting Wit in an existing app
Four levels, each complete on its own, each reusing what you wrote for the level below.
An app that already has its records, its server, its forms and its workflow does not have to hand them over to use Wit. Adopt it a level at a time: each level is worth having on its own, and climbing one never means rewriting the one below — the field types you write first carry every level after.
1. A projection: your register as a grid
Show your records in a grid: sort, filter, group, resize and reorder columns, saved views, export. Your server keeps
paging and querying (rowModelType: 'server' with your datasource), and opening a record can still be your own page.
What to write: a field type per kind of value you have (defineFieldType): money, a quantity with its unit, a
link to another register, a user. Describe them to Wit rather than drawing opaque values into cells with a renderer of
your own: then sorting, filtering, export, copy and paste understand them, and every later level reuses them.
2. Editing in the grid
Edit in place, paste and fill, and run your actions as commands on the selection. Saving goes through your API with
data.save (on a server-side grid too): changes queue, your answer patches the records, a refusal rolls back with its
reason, and save.version sends the version each change was based on. Your validation runs as data.rules, or as
your own engine's answers through capabilities (canEdit, canShow).
What to write: a save adapter for your endpoint, and the actions your users take on records, as commands.
3. The entry: a record in depth
A record's fields laid out your way (createRecordForm, or inspector.layout), each its field type's own control,
bound to the record or a draft; a section that applies only at some stage; the record's rows (an order's lines, a
form's table) as a collection edited in a grid bound to the record, saved with it. Your server's own
operations — submit a step, approve, confirm — are commands that send (what the server decides),
with drafts applied and changes saved first.
What to write: the layouts, and an operation per server action. Your workflow, approvals and audit stay on your server.
4. The workspace
Your records in more than one view — a board by stage, a calendar, your own view types (defineViewType) for the
jobs only your app has — with the inspector, the bulk bar and the palette around them. Keep your own header if you
like: the workspace's state and its bar's parts are yours to place.
What to write: your view types, and whatever you compose into the bar, the menus and the inspector.
What stays yours
Wit presents and edits records and runs your operations; it does not replace your server. Your schema, your persistence and transactions, your authorisation, your workflow engine and your audit trail stay where they are, and Wit's guarantees end where your server's begin: see Collections and entries.
Last updated on