From 6ec14c3d17039e64ceed6121c3bac31654151d76 Mon Sep 17 00:00:00 2001 From: delchev Date: Sun, 9 Aug 2026 10:15:45 +0300 Subject: [PATCH 1/2] clarify: a calendar view adds a page; a document's line-items calendar is the items pane `view: calendar` / `view: range` were described as rendering an entity "as a time-based page instead of a table", which read as - and was implemented as - replacing the entity's page family. That cost a document master its document editor: declaring a calendar took away the line items, printing and workflow tasks. State the additive rule instead. The entity keeps the pages its structure implies and the calendar joins them: / is the calendar, //list the entity's own browse page, and create / edit stay the entity's own - so a document may be browsed on a calendar and still edited as a document. `view: slots` is called out as the exception, since a slot picker is an authoring surface rather than a second way to browse. Also document the line-items case: when the entity declaring `view: calendar` is a document's items child, the document's items pane IS the calendar - the shape for a day-grained line - and cannot also be a chat thread. Co-Authored-By: Claude Opus 5 --- versions/1.0.md | 36 ++++++++++++++++++++++++++++++++++-- 1 file changed, 34 insertions(+), 2 deletions(-) diff --git a/versions/1.0.md b/versions/1.0.md index d10146a..0fa97d3 100644 --- a/versions/1.0.md +++ b/versions/1.0.md @@ -744,7 +744,7 @@ widgets: ### view — calendar, range, slots -`view:` (with a `calendar:` / `slots:` descriptor) renders an entity as a time-based page instead of a table: +`view:` (with a `calendar:` / `slots:` descriptor) places an entity's records on a time surface: ```yaml - name: DayAllocation @@ -760,6 +760,38 @@ widgets: `view: calendar` is also expressible as the role alias `function: Calendar`. +#### A calendar is an additional page + +`view: calendar` and `view: range` **add** a page; they never take one away. The entity keeps the page family its structure already implies — a list, a master-detail, or a document editor — and the calendar joins it: + +| Route | Page | +| --- | --- | +| `/` | the calendar | +| `//list` | the entity's own browse page (list / master / document list) | +| `//create`, `///edit` | the entity's own editor | + +Both browse pages offer a switch to the other, and clicking a day or an event on the calendar opens the entity's own editor. So a document master may be browsed on a calendar and still be edited as a document, with its line items, printing and workflow tasks intact — declaring a calendar never costs an entity its editing surface. + +`view: slots` is the exception: a slot picker is an authoring surface — pick a free slot, create a record — rather than a second way to browse the same records, so it does replace the browse page. + +#### A document's line items on a calendar + +When the entity declaring `view: calendar` is a document's **line-items** child, the document's items pane *is* the calendar instead of the row grid — the shape for a day-grained line, such as a booked day or an allocated hour: + +```yaml +- name: Roster + function: Document +- name: RosterItem + function: DocumentItem + view: calendar + calendar: { start: day, title: Person } + fields: + - { name: day, type: date, required: true } + - { name: hours, type: decimal, precision: 18, scale: 2 } +``` + +The document keeps its header, totals and printing; only the items pane changes. Clicking an event edits that line, clicking an empty day adds one with that date filled in. A line-items child cannot be both a calendar and a chat thread (`documentItemsLayout: chat`) — the two claim the same pane, and declaring both is an error. + ### documentItemsLayout: chat — conversation threads A document master can render its line-items child as a chat thread (message bubbles + a composer) instead of an editable items table — support cases, tickets, comment threads. The header, status pill, workflow tasks and print stay as in a normal document: @@ -1148,7 +1180,7 @@ One line per construct, linking into the chapters above. | [`function: Attachment` / `Snapshot`](#attachments-and-snapshots) | a Files panel / immutable versioned printed copies | | [`forms`](#forms) | task data-entry pages | | [`actions`](#actions--custom-buttons) | developer-defined buttons opening custom pages | -| [`view`](#view--calendar-range-slots) | calendar / range / slot-booking pages | +| [`view`](#view--calendar-range-slots) | an additional calendar / range page, or a slot-booking page | | [`documentItemsLayout: chat`](#documentitemslayout-chat--conversation-threads) | render a document's items as a chat thread | | [`reports`](#reports) | aggregations, charts, dashboard KPI tiles, balance reports | | [`widgets`](#widgets--custom-dashboard-tiles) | custom KPI / embedded-page dashboard tiles | From 9b89e5c0e1d6de4ed69fbd318e62e1081732b037 Mon Sep 17 00:00:00 2001 From: delchev Date: Sun, 9 Aug 2026 10:34:33 +0300 Subject: [PATCH 2/2] clarify: the slot picker adds a page too, so no view replaces a layout The previous revision carved `view: slots` out as the exception that still replaces the entity's browse page. That reasoning does not hold: a picker is how a record is CREATED, and the list or document page is how it is worked with afterwards - an author needs both, and a booking document lost its document editor exactly as a calendar-browsed one did. Generalise the rule to every view. Co-Authored-By: Claude Opus 5 --- versions/1.0.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/versions/1.0.md b/versions/1.0.md index 0fa97d3..9a487be 100644 --- a/versions/1.0.md +++ b/versions/1.0.md @@ -760,19 +760,17 @@ widgets: `view: calendar` is also expressible as the role alias `function: Calendar`. -#### A calendar is an additional page +#### A view adds a page -`view: calendar` and `view: range` **add** a page; they never take one away. The entity keeps the page family its structure already implies — a list, a master-detail, or a document editor — and the calendar joins it: +`view: calendar`, `view: range` and `view: slots` **add** a page; they never take one away. The entity keeps the page family its structure already implies — a list, a master-detail, or a document editor — and the view joins it: | Route | Page | | --- | --- | -| `/` | the calendar | +| `/` | the calendar, or the slot picker | | `//list` | the entity's own browse page (list / master / document list) | | `//create`, `///edit` | the entity's own editor | -Both browse pages offer a switch to the other, and clicking a day or an event on the calendar opens the entity's own editor. So a document master may be browsed on a calendar and still be edited as a document, with its line items, printing and workflow tasks intact — declaring a calendar never costs an entity its editing surface. - -`view: slots` is the exception: a slot picker is an authoring surface — pick a free slot, create a record — rather than a second way to browse the same records, so it does replace the browse page. +Both browse pages offer a switch to the other, and choosing a day, an event or a free slot opens the entity's own editor. So a document master may be browsed on a calendar — or booked from a slot picker — and still be edited as a document, with its line items, printing and workflow tasks intact: declaring a view never costs an entity its editing surface. A picker is how a record is *created*; the list or document page is how it is worked with afterwards, and an author needs both. #### A document's line items on a calendar