feat(18.1-01): task 3 flat reorder on the server
- config_reorder.yaml without parentColumn on a record with no parent_id column compiles as a flat (WinterCMS Sortable) reorder; maxDepth above 0 on it fails boot, an explicit parentColumn still means a tree - ListReorder.Flat and AdminReorderTree.Flat (flat, omitempty); flat nodes carry parent_id null, a save writes only the sort column, a parent is a 422 on nodes (reorder.flat_parent); 409 and duplicate rules unchanged - swag descriptions, OpenAPI and schema.d.ts regenerated - acme.catalog badges reorder fixture, TestReorderFlatCompile and TestReorderFlatSmoke; docs Flat reorder section and cabana README
This commit is contained in:
@@ -189,7 +189,7 @@ A list that shows soft-deleted records includes them in its scope, as `withTrash
|
||||
|
||||
## Tree reorder
|
||||
|
||||
A controller whose records form a tree (a `parent_id` and a `sort_order` column, such as menu entries) gets a drag-and-drop reorder page, the successor of WinterCMS's ReorderController. It needs a `config_reorder.yaml` next to `config_list.yaml` and the built-in `reorder` button in `toolbar.buttons`:
|
||||
A controller whose records form a tree (a `parent_id` and a `sort_order` column, such as menu entries) gets a drag-and-drop reorder page, the successor of WinterCMS's ReorderController. Records without a parent column get the same page as a plain ordered list; see [Flat reorder](#flat-reorder). It needs a `config_reorder.yaml` next to `config_list.yaml` and the built-in `reorder` button in `toolbar.buttons`:
|
||||
|
||||
```yaml src=modules/cabana/testdata/companions/controllers/links/config_reorder.yaml
|
||||
title: Reorder links
|
||||
@@ -209,7 +209,7 @@ partition:
|
||||
| `title` | The page title, a translation key or text. |
|
||||
| `nameFrom` | The column a node shows. |
|
||||
| `modelClass` | Optional; when set it must equal the controller's model name, as in WinterCMS's `reorder_config.yaml`. |
|
||||
| `parentColumn`, `sortColumn` | The tree columns, `parent_id` and `sort_order` by default. Both are written by a save. |
|
||||
| `parentColumn`, `sortColumn` | The tree columns, `parent_id` and `sort_order` by default. Both are written by a save. Without `parentColumn` on a record that has no `parent_id` column the reorder is [flat](#flat-reorder). |
|
||||
| `maxDepth` | The deepest level a node may sit at, counting the top level as 1; 0 (the default) is unlimited. |
|
||||
| `partition` | Optional: reorder within one value of a column, such as the entries of one menu. `column` is that column, `relation` the form's `type: relation` belongsTo field over it (its options, scoped by `pact.RelationExtendOptionsQuery`, are the partitions offered), `nameFrom` an optional label column of the related record and `label` the selector's label. |
|
||||
|
||||
@@ -227,6 +227,20 @@ Both routes need the controller's permissions; the save is a write route (CSRF h
|
||||
|
||||
In the admin, a list whose schema carries `reorder` shows a "Reorder records" button before "New record". It opens the reorder page, and when the list is filtered on the partition column it opens that partition. The page shows the tree with a drag handle and move up, move down, outdent and indent buttons on every row. A row can also be dragged before, after or into another row (never into its own subtree), and the arrow keys on a focused handle move it the same way as the buttons. There is no Save button: 400 ms after the last move the page posts the whole set, shows "Order saved", and sends a pending save at once when the administrator leaves. Only one save is in flight at a time: moves made while it runs are sent after it settles, with the tree as it is then, so the stored order never ends older than the screen. A refused save puts the last saved order back, unless a later save is waiting (it carries the whole tree); a 409 reloads the tree. A save that settles after the page switched partition does not touch the new partition's tree. A partitioned page has a selector for the partition.
|
||||
|
||||
## Flat reorder
|
||||
|
||||
A record with an order but no parent (WinterCMS's Sortable trait: a `sort_order` column and no `parent_id`) uses the same `config_reorder.yaml` without `parentColumn`. A WinterCMS `reorder_config.yaml` of such a controller compiles unchanged:
|
||||
|
||||
```yaml src=modules/cabana/testdata/catalog/controllers/badges/config_reorder.yaml
|
||||
title: Reorder badges
|
||||
nameFrom: name
|
||||
modelClass: Badge
|
||||
```
|
||||
|
||||
The reorder is flat when the file names no `parentColumn` and the controller's record has no `parent_id` column, as WinterCMS infers a Sortable model. An explicit `parentColumn` always means a tree and still stops the start-up when it is not a column, and a record with a `parent_id` column keeps the tree reorder. `nameFrom`, `sortColumn`, `modelClass` and `partition` work as on a tree; `maxDepth` above 0 on a flat reorder stops the start-up.
|
||||
|
||||
The list schema's `reorder` and the data of both reorder routes carry `flat: true`; a tree reorder omits the key, so its payloads are unchanged. Every node of a flat reorder has `parent_id: null`. A save writes only the sort column, without running the model's save hooks. A node whose `parent_id` is not null is a 422 `validation_failed` on `nodes` with `reorder.flat_parent`; the duplicate-id 422 and the 409 `reorder_stale` set rule are the same as on a tree.
|
||||
|
||||
## Remembered list state
|
||||
|
||||
The admin keeps a list's search, sort, filters, page and page size in the URL, so a filtered list can be bookmarked or shared. It also remembers the last of these per list in the browser's local storage. When an administrator opens a list without any of these parameters in the URL (from the navigation, a breadcrumb or a form's back, save or delete), the admin restores the remembered query. A URL that carries list parameters wins and replaces the remembered query.
|
||||
|
||||
Reference in New Issue
Block a user