Skip to content

clarify: a calendar view adds a page; a document's line-items calendar is the items pane - #5

Open
delchev wants to merge 2 commits into
mainfrom
clarify/calendar-additional-page
Open

clarify: a calendar view adds a page; a document's line-items calendar is the items pane#5
delchev wants to merge 2 commits into
mainfrom
clarify/calendar-additional-page

Conversation

@delchev

@delchev delchev commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

view: calendar / view: range were described as rendering an entity "as a time-based page instead of a table". Read literally — and implemented literally — that replaces the entity's page family, which costs a document master its document editor: declaring a calendar took away the line items, printing and workflow tasks, so an author had to choose between the calendar and the document.

This states the additive rule instead:

  • the entity keeps the pages its structure implies, and the calendar joins them — /<Entity> the calendar, /<Entity>/list the entity's own browse page, create / edit unchanged;
  • so a document master may be browsed on a calendar and still be edited as a document;
  • view: slots is called out as the exception, because a slot picker is an authoring surface (pick a free slot, create a record) rather than a second way to browse the same records.

It also documents the line-items case, which had no wording at all: 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 such as a booked day or an allocated hour — and cannot also be a chat thread, since the two claim the same pane.

The view row of the DSL index is reworded to match.

Reference implementation: eclipse-dirigible/dirigible#6624 (issues #6547 and #6482 there). The website chapter follows in IntentFile/intentfile.github.io.

…r 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: /<Entity> is the calendar, /<Entity>/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 <noreply@anthropic.com>
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 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant