@cratis/scene.blueprint.components 0.1.0

package/templates/listTemplates.ts

@@ -0,0 +1,142 @@
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+import { ScreenTemplate, WidthSizeClass } from '@cratis/scene.model';
+import { SlotName, TemplateSlotName, column, row, slotLeaf } from '@cratis/scene.blueprint.default';
+import { dataPage, invoiceColumns, invoiceTableOptions, observableDataTable } from './dataElements';
+import { objectContentEditor, objectNavigationalBar, timeMachine } from './editorElements';
+import { arcPageHeader, page, toolbar, toolbarButton, toolbarGroup, toolbarSeparator } from './elements';
+import { SampleBindingName } from './SampleBindingName';
+
+/**
+ * The three list shapes an Arc application repeats: a list, a live list, and a list with the selected
+ * record beside it.
+ *
+ * All three fill the application shell's `content` slot, which is the only slot the default blueprint's
+ * `AppShell` layout declares for a screen - so an application that has picked the default blueprint can
+ * drop any of these in without arranging anything.
+ *
+ * What makes them worth shipping is what is *already wired*. A list page is not "a table in a slot"; it is
+ * a query name, a set of columns, an empty message, a data key, a filter field list, a header that states
+ * what the page is bound to, and an action bar. Every one of those is a decision, and repeating all seven
+ * per screen is how a list page ends up subtly different on every screen of an application.
+ */
+
+/**
+ * The archetype: a `dataPage` filling the body, under a header that says what it is bound to.
+ *
+ * `dataPage` is the single highest-leverage name `Cratis.Components` exposes - the library's whole
+ * list-screen composite, with its title bar, menubar, filterable table and optional details pane driven
+ * from one query. Building the same thing out of a `table` and a `toolbar` in a screen is pages of
+ * modeling for a worse result, and this template is the answer to that: an application supplies a query
+ * name and has a working list page.
+ */
+export const dataListPageTemplate: ScreenTemplate = {
+    name: 'DataListPage',
+    fitsSlot: SlotName.Content,
+    slots: [{ name: TemplateSlotName.Header }, { name: TemplateSlotName.Body }],
+    content: {
+        [TemplateSlotName.Header]: [
+            arcPageHeader(
+                'data-list-header',
+                { title: 'Invoices', subtitle: 'Every invoice, filterable and paged against the server', section: 'Billing', query: SampleBindingName.AllInvoices },
+                [
+                    toolbar('data-list-actions', [
+                        toolbarButton('data-list-new', 'Register an invoice', 'pi pi-plus', 'New'),
+                        toolbarButton('data-list-refresh', 'Refresh', 'pi pi-refresh'),
+                        toolbarSeparator('data-list-separator'),
+                        toolbarGroup('data-list-export', [
+                            toolbarButton('data-list-download', 'Download as CSV', 'pi pi-download'),
+                            toolbarButton('data-list-print', 'Print', 'pi pi-print'),
+                        ]),
+                    ]),
+                ],
+            ),
+        ],
+        [TemplateSlotName.Body]: [dataPage('data-list-body', SampleBindingName.AllInvoices, invoiceTableOptions, invoiceColumns)],
+    },
+    displayName: 'Data list page',
+    description: 'A dataPage bound to one query, under a header that states the binding - the whole list screen in two elements.',
+};
+
+/**
+ * The live variant: the same page shape over an observable query.
+ *
+ * A separate template rather than a flag, for the same reason `observableDataTable` is a separate name
+ * from `dataTable`: the difference lives in the *proxy* a host registers, not in how the page is
+ * configured. An observable query opens a subscription and the page re-renders when the read model
+ * changes on the server. Choosing this template is an application saying its data is live, and that is a
+ * decision worth being able to read off the screen rather than infer from a property.
+ */
+export const observableDataListPageTemplate: ScreenTemplate = {
+    name: 'ObservableDataListPage',
+    fitsSlot: SlotName.Content,
+    slots: [{ name: TemplateSlotName.Header }, { name: TemplateSlotName.Body }],
+    content: {
+        [TemplateSlotName.Header]: [
+            arcPageHeader('observable-list-header', {
+                title: 'Invoices in flight',
+                subtitle: 'Updates as the read model changes - no refresh button, because there is nothing to refresh',
+                section: 'Billing',
+                query: SampleBindingName.InvoicesInFlight,
+            }),
+        ],
+        [TemplateSlotName.Body]: [
+            page('observable-list-body', 'In flight', [
+                observableDataTable('observable-list-table', SampleBindingName.InvoicesInFlight, invoiceTableOptions, invoiceColumns),
+            ]),
+        ],
+    },
+    displayName: 'Observable data list page',
+    description: 'A live list over an observable query, which re-renders when the read model changes on the server.',
+};
+
+/**
+ * List plus detail: the whole list screen, with the selected record's document and history beside it.
+ *
+ * The detail region is built from the library's Arc-free editors, which is the interesting part. They read
+ * their content out of the property bag rather than from a query, so this half of the page renders fully
+ * at design time while the list half is still a placeholder - and in an event-sourced application the
+ * record's *history* is as natural a thing to show as its current values, which is why the time machine is
+ * here rather than in some optional extra.
+ *
+ * Its arrangement drops the detail column below the list at a compact width, because a document editor and
+ * a paged table side by side on a phone are two unreadable slivers.
+ */
+export const dataListWithDetailPageTemplate: ScreenTemplate = {
+    name: 'DataListWithDetailPage',
+    fitsSlot: SlotName.Content,
+    slots: [{ name: TemplateSlotName.Header }, { name: TemplateSlotName.Body }, { name: TemplateSlotName.SidePanel }],
+    arrangement: {
+        root: column([slotLeaf(TemplateSlotName.Header), row([slotLeaf(TemplateSlotName.Body, { grow: 2 }), slotLeaf(TemplateSlotName.SidePanel, { grow: 1 })], 16)]),
+        overrides: [
+            {
+                width: WidthSizeClass.Compact,
+                root: column([slotLeaf(TemplateSlotName.Header), slotLeaf(TemplateSlotName.Body), slotLeaf(TemplateSlotName.SidePanel)], 16),
+            },
+        ],
+    },
+    content: {
+        [TemplateSlotName.Header]: [
+            arcPageHeader('list-detail-header', {
+                title: 'Invoices',
+                subtitle: 'The list, with the selected invoice beside it',
+                section: 'Billing',
+                query: SampleBindingName.AllInvoices,
+            }),
+        ],
+        [TemplateSlotName.Body]: [dataPage('list-detail-body', SampleBindingName.AllInvoices, invoiceTableOptions, invoiceColumns)],
+        [TemplateSlotName.SidePanel]: [
+            page('list-detail-panel', 'Selected invoice', [
+                objectNavigationalBar('list-detail-trail'),
+                objectContentEditor('list-detail-document', false),
+                timeMachine('list-detail-history'),
+            ]),
+        ],
+    },
+    displayName: 'Data list with detail page',
+    description: 'A dataPage beside a detail region showing the selected record document and its history.',
+};
+
+/** The three list-shaped templates. */
+export const listTemplates: ScreenTemplate[] = [dataListPageTemplate, observableDataListPageTemplate, dataListWithDetailPageTemplate];

package/templates/nesting.ts

@@ -0,0 +1,118 @@
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+import { ScreenTemplate } from '@cratis/scene.model';
+import { SlotName, TemplateSlotName } from '@cratis/scene.blueprint.default';
+import { invoiceColumns, invoiceTableOptions, observableDataTable } from './dataElements';
+import { filterPanel } from './editorElements';
+import { arcPageHeader, page, toolbar, toolbarButton, toolbarSeparator } from './elements';
+import { SampleBindingName } from './SampleBindingName';
+
+/**
+ * A worked three-level chain, from the application layout down to one behavior.
+ *
+ * The nesting rule is one rule applied at every depth: a template names, in `fitsSlot`, a slot declared by
+ * whatever contains it. A module's template fits the application layout's `content`; a feature's fits a
+ * slot the module's declares; a slice's fits one the feature's declares. Nothing here is a special case
+ * for a particular level, which is exactly why the hierarchy can be arbitrarily deep with no second
+ * mechanism.
+ *
+ * The slot names are chosen so that each fitted name is declared by exactly one container in the chain -
+ * `body` only by the module, `primary` only by the feature. That is not decoration: `resolveScreenTemplates`
+ * places a template only when the containers in scope agree on exactly one home for it, and reports it as
+ * unplaced rather than guessing when two of them declare the same name. A chain that reused `body` at
+ * three levels would read fine and resolve to nothing.
+ *
+ * The whole chain is Arc-bound, which is the point of it living in *this* blueprint rather than being a
+ * second copy of the default one's. It ends where a Cratis slice really ends: a button that summons the
+ * command dialog.
+ */
+
+/**
+ * Module level: fits the application shell's `content` slot.
+ *
+ * A module always has a name and a description, so it brings its own header, and it offers a body for the
+ * feature inside it plus a side panel for the filters that apply across the whole module.
+ */
+export const dataModulePageTemplate: ScreenTemplate = {
+    name: 'DataModulePage',
+    fitsSlot: SlotName.Content,
+    slots: [{ name: TemplateSlotName.Header }, { name: TemplateSlotName.Body }, { name: TemplateSlotName.SidePanel }],
+    content: {
+        [TemplateSlotName.Header]: [
+            arcPageHeader('module-header', {
+                title: 'Billing',
+                subtitle: 'Everything the billing module owns',
+                section: 'Operations',
+            }),
+        ],
+        [TemplateSlotName.SidePanel]: [page('module-filters', 'Filters', [filterPanel('module-filter-panel', 'Filter the module')])],
+    },
+    displayName: 'Data module page',
+    description: 'Module level: fits the application layout content slot and offers a body for one feature.',
+};
+
+/**
+ * Feature level: fits the module page's `body` slot.
+ *
+ * A feature is where actions belong - a module is a grouping and a slice is one behavior, and the feature
+ * in between is what a user thinks of as "the screen with the buttons on it". It offers a primary region
+ * for the slice and a secondary one for the live view of what that slice is doing.
+ */
+export const dataFeatureSectionTemplate: ScreenTemplate = {
+    name: 'DataFeatureSection',
+    fitsSlot: TemplateSlotName.Body,
+    slots: [{ name: TemplateSlotName.Toolbar }, { name: TemplateSlotName.Primary }, { name: TemplateSlotName.Secondary }],
+    content: {
+        [TemplateSlotName.Toolbar]: [
+            toolbar('feature-toolbar', [
+                toolbarButton('feature-new', 'Register an invoice', 'pi pi-plus', 'New'),
+                toolbarButton('feature-adjust', 'Record an adjustment', 'pi pi-pencil', 'Adjust'),
+                toolbarSeparator('feature-separator'),
+                toolbarButton('feature-export', 'Export the feature data', 'pi pi-download'),
+            ]),
+        ],
+        [TemplateSlotName.Secondary]: [
+            page('feature-live', 'In flight', [
+                observableDataTable('feature-live-table', SampleBindingName.InvoicesInFlight, invoiceTableOptions, invoiceColumns),
+            ]),
+        ],
+    },
+    displayName: 'Data feature section',
+    description: 'Feature level: fits a module page body slot, brings the action toolbar and a live view.',
+};
+
+/**
+ * Slice level: fits the feature section's `primary` slot.
+ *
+ * The end of the chain, and deliberately the thinnest thing in it. A slice is one behavior, and in a
+ * Cratis application that behavior is one command - so its surface is a header saying what the command is
+ * and whether it is wired, and the action that summons it. The capture itself happens in the `CommandDialog`
+ * dialog template, which is why this template has no form on it and does not need one.
+ */
+export const commandSliceSectionTemplate: ScreenTemplate = {
+    name: 'CommandSliceSection',
+    fitsSlot: TemplateSlotName.Primary,
+    slots: [{ name: TemplateSlotName.Header }, { name: TemplateSlotName.Actions }],
+    content: {
+        [TemplateSlotName.Header]: [
+            arcPageHeader('slice-header', {
+                title: 'Record an adjustment',
+                subtitle: 'One behavior, one command, one button',
+                section: 'Adjustments',
+                command: SampleBindingName.RecordAdjustment,
+            }),
+        ],
+        [TemplateSlotName.Actions]: [
+            toolbar('slice-actions', [
+                toolbarButton('slice-record', 'Record an adjustment', 'pi pi-check', 'Record'),
+                toolbarButton('slice-cancel', 'Leave the invoice as it is', 'pi pi-times', 'Cancel'),
+            ]),
+        ],
+    },
+    displayName: 'Command slice section',
+    description: 'Slice level: fits a feature section primary slot and hosts one command behavior.',
+};
+
+/** The chain, outermost first - what a spec walks to prove `fitsSlot` resolves at every level. */
+export const nestingChainTemplates: ScreenTemplate[] = [dataModulePageTemplate, dataFeatureSectionTemplate, commandSliceSectionTemplate];

package/templates/sampleData.ts

@@ -0,0 +1,81 @@
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+/**
+ * The seeded content the Arc-free composites in this package's templates render.
+ *
+ * There is a real split running through this blueprint, and it is worth naming rather than hiding. Most of
+ * `@cratis/components` is Arc-bound: a data page, a table, a command form and a command dialog all need a
+ * registered proxy and a live backend before they show anything, so at design time they are placeholders,
+ * and that is correct.
+ *
+ * The editors are not. A schema editor, a document editor, a navigational bar and a time machine all take
+ * their content from the property bag, so a template that seeds them renders as a working page with no
+ * backend at all. That is why the editor templates carry this data: it makes two of this package's pages
+ * genuinely usable in a preview, rather than eight pages of dashed boxes.
+ *
+ * The shape is an invoice throughout, matching the query and command names the other templates bind to, so
+ * the whole package reads as one small application rather than eight unrelated demonstrations.
+ */
+
+/** A JSON schema in the shape Chronicle emits for an event type - what `schemaEditor` edits. */
+export const invoiceSchema: Record<string, unknown> = {
+    title: 'InvoiceRegistered',
+    type: 'object',
+    properties: {
+        number: { type: 'string', description: 'The invoice number as printed on the document.' },
+        customer: { type: 'string', description: 'The customer the invoice is addressed to.' },
+        issued: { type: 'string', format: 'date-time', description: 'When the invoice was issued.' },
+        amount: { type: 'number', description: 'The gross amount, in the invoice currency.' },
+        currency: { type: 'string', description: 'The ISO currency code.' },
+    },
+};
+
+/** One invoice as a plain document - what `objectContentEditor` renders against {@link invoiceSchema}. */
+export const invoiceDocument: Record<string, unknown> = {
+    number: 'INV-2043',
+    customer: 'Northwind Traders',
+    issued: '2026-01-05T09:30:00Z',
+    amount: 4200,
+    currency: 'USD',
+};
+
+/** Where in the document the navigational bar currently is. */
+export const invoiceNavigationPath: string[] = ['lines', 'shipping'];
+
+/**
+ * Successive versions of the invoice, for the time machine.
+ *
+ * Every entry has an id, a label and a parseable timestamp, because the adapter drops any that does not -
+ * a version invented at the epoch would not be a slightly wrong entry, it would silently reorder every
+ * real one around it.
+ */
+export const invoiceVersions: Record<string, unknown>[] = [
+    { id: 'v3', label: 'Adjustment recorded', timestamp: '2026-01-12T14:05:00Z', content: 'Amount reduced by 120.00 - damaged goods' },
+    { id: 'v2', label: 'Approved', timestamp: '2026-01-07T08:15:00Z', content: 'Approved by Amelia Nyquist' },
+    { id: 'v1', label: 'Registered', timestamp: '2026-01-05T09:30:00Z', content: 'Registered from the supplier portal' },
+];
+
+/** The filters the list templates offer, in the shape `filterPanel` reads. */
+export const invoiceFilters: Record<string, unknown>[] = [
+    {
+        key: 'status',
+        label: 'Status',
+        type: 'string',
+        multi: true,
+        options: [
+            { key: 'draft', label: 'Draft', count: 12 },
+            { key: 'approved', label: 'Approved', count: 44 },
+            { key: 'paid', label: 'Paid', count: 108 },
+        ],
+    },
+    { key: 'amount', label: 'Amount', type: 'number', buckets: 4 },
+    { key: 'issued', label: 'Issued', type: 'date' },
+];
+
+/** The status choices a command form's dropdown offers. */
+export const statusOptions: { label: string; value: string }[] = [
+    { label: 'Draft', value: 'draft' },
+    { label: 'Approved', value: 'approved' },
+    { label: 'Paid', value: 'paid' },
+];

package/templates/screenTemplates.ts

@@ -0,0 +1,35 @@
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+import { ScreenTemplate } from '@cratis/scene.model';
+import { commandTemplates } from './commandTemplates';
+import { editorTemplates } from './editorTemplates';
+import { listTemplates } from './listTemplates';
+import { nestingChainTemplates } from './nesting';
+import { workspaceTemplates } from './workspaceTemplates';
+
+/**
+ * The screen templates this blueprint provides.
+ *
+ * Eight whole pages that fill the application shell's `content` slot, plus the three-level chain that
+ * demonstrates how `fitsSlot` composes at module, feature and slice level. The list is what the manifest's
+ * `screenTemplates` names and what the bundle provides; `validatePackageBundle` proves the two agree.
+ */
+export const componentsScreenTemplates: ScreenTemplate[] = [
+    ...listTemplates,
+    ...workspaceTemplates,
+    ...commandTemplates,
+    ...editorTemplates,
+    ...nestingChainTemplates,
+];
+
+/**
+ * The eight templates that fill the application layout's own `content` slot directly.
+ *
+ * Kept apart from the nesting chain because `fitsSlot` is resolved against *the containers in scope*, and
+ * these two groups are never in scope together. Each of these is a whole page an application places on its
+ * own; the chain's three are one page assembled from three levels. Resolving them as one set would ask
+ * `resolveScreenTemplates` which of eight `body`-declaring templates the feature section belongs to, and it
+ * would rightly answer that it cannot tell.
+ */
+export const componentsPageTemplates: ScreenTemplate[] = [...listTemplates, ...workspaceTemplates, ...commandTemplates, ...editorTemplates];

package/templates/workspaceTemplates.ts

@@ -0,0 +1,163 @@
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+import { ScreenTemplate, WidthSizeClass } from '@cratis/scene.model';
+import { SlotName, TemplateSlotName, column, grid, slotLeaf } from '@cratis/scene.blueprint.default';
+import { ColumnDefinition } from './ColumnDefinition';
+import { adjustmentColumns, dataTable, invoiceColumns, invoiceTableOptions, observableDataTable } from './dataElements';
+import { objectContentEditor, timeMachine } from './editorElements';
+import { arcPageHeader, page } from './elements';
+import { SampleBindingName } from './SampleBindingName';
+import { TableOptions } from './TableOptions';
+
+/**
+ * The two whole-workspace shapes: a master-detail arrangement, and a dashboard of data widgets.
+ *
+ * Both are arrangements of *several* bindings rather than one, which is what separates them from the list
+ * templates. That is also what makes them the templates most worth shipping: an application can wire one
+ * query without help, and gets a page that looks like every other page in the product only if something
+ * has already decided how four of them sit together.
+ */
+
+/** The columns of the revenue widget's query. */
+const revenueColumns: ColumnDefinition[] = [
+    { field: 'month', header: 'Month' },
+    { field: 'invoiced', header: 'Invoiced' },
+    { field: 'collected', header: 'Collected' },
+];
+
+/** The columns of the open-tickets widget's query. */
+const ticketColumns: ColumnDefinition[] = [
+    { field: 'reference', header: 'Reference' },
+    { field: 'subject', header: 'Subject' },
+    { field: 'age', header: 'Age' },
+];
+
+/** Table options for a widget-sized table, where there is no search box to filter across. */
+const widgetTableOptions: TableOptions = { emptyMessage: 'Nothing to show yet', dataKey: 'id' };
+
+/**
+ * Master and detail: the list in the larger column, the selected record in the narrower one.
+ *
+ * The difference from `DataListWithDetailPage` is real and worth having both. That template is a whole
+ * `dataPage` - its own title bar, menubar and filtering - with a detail region added beside it. This one is
+ * a plain `dataTable` next to a detail region, which is the right shape when the page's chrome comes from
+ * the *feature* around it rather than from the list itself. Reaching for the wrong one shows up as a page
+ * with two toolbars.
+ *
+ * The grid collapses to a single column at a compact width, because a master and a detail side by side on a
+ * phone is the arrangement that made "master-detail does not work on mobile" a truism.
+ */
+export const masterDetailPageTemplate: ScreenTemplate = {
+    name: 'MasterDetailPage',
+    fitsSlot: SlotName.Content,
+    slots: [{ name: TemplateSlotName.Header }, { name: TemplateSlotName.Primary }, { name: TemplateSlotName.Secondary }],
+    arrangement: {
+        root: column([slotLeaf(TemplateSlotName.Header), grid([slotLeaf(TemplateSlotName.Primary, { span: 2 }), slotLeaf(TemplateSlotName.Secondary)], 3, 16)]),
+        overrides: [
+            {
+                width: WidthSizeClass.Compact,
+                root: column([slotLeaf(TemplateSlotName.Header), slotLeaf(TemplateSlotName.Primary), slotLeaf(TemplateSlotName.Secondary)], 16),
+            },
+        ],
+    },
+    content: {
+        [TemplateSlotName.Header]: [
+            arcPageHeader('master-detail-header', {
+                title: 'Invoices',
+                subtitle: 'Pick an invoice on the left to inspect it on the right',
+                section: 'Billing',
+                query: SampleBindingName.AllInvoices,
+            }),
+        ],
+        [TemplateSlotName.Primary]: [
+            page('master-detail-master', 'Invoices', [dataTable('master-detail-table', SampleBindingName.AllInvoices, invoiceTableOptions, invoiceColumns)]),
+        ],
+        [TemplateSlotName.Secondary]: [
+            page('master-detail-detail', 'Selected invoice', [
+                objectContentEditor('master-detail-document', false),
+                timeMachine('master-detail-history'),
+            ]),
+        ],
+    },
+    displayName: 'Master-detail page',
+    description: 'A queried list in the larger column with the selected record and its history in the narrower one.',
+};
+
+/**
+ * A dashboard of data widgets - four queries arranged so the page reads in the order people already read it.
+ *
+ * The composition is the one every template line settles on: a row of figures across the top, then a wide
+ * column and a narrow one. Copying it is the point rather than a shortcut - it is the arrangement the eye
+ * already knows how to scan, and a dashboard that invents its own costs the reader a moment on every visit.
+ *
+ * What this blueprint adds is that every widget is a *query*, not a picture. Each one names a proxy a host
+ * registers, so the dashboard is live the moment the application wires it, with nothing to replace.
+ */
+export const dashboardPageTemplate: ScreenTemplate = {
+    name: 'DashboardPage',
+    fitsSlot: SlotName.Content,
+    slots: [
+        { name: TemplateSlotName.Header },
+        { name: TemplateSlotName.Stats },
+        { name: TemplateSlotName.Primary },
+        { name: TemplateSlotName.Secondary },
+    ],
+    arrangement: {
+        root: column([
+            slotLeaf(TemplateSlotName.Header),
+            slotLeaf(TemplateSlotName.Stats),
+            grid([slotLeaf(TemplateSlotName.Primary, { span: 2 }), slotLeaf(TemplateSlotName.Secondary)], 3, 16),
+        ]),
+        overrides: [
+            {
+                width: WidthSizeClass.Compact,
+                root: column(
+                    [
+                        slotLeaf(TemplateSlotName.Header),
+                        slotLeaf(TemplateSlotName.Stats),
+                        slotLeaf(TemplateSlotName.Primary),
+                        slotLeaf(TemplateSlotName.Secondary),
+                    ],
+                    16,
+                ),
+            },
+        ],
+    },
+    content: {
+        [TemplateSlotName.Header]: [
+            arcPageHeader('dashboard-header', {
+                title: 'Billing',
+                subtitle: 'Four queries, arranged the way people already read a dashboard',
+                section: 'Operations',
+                query: SampleBindingName.RevenueByMonth,
+            }),
+        ],
+        [TemplateSlotName.Stats]: [
+            page('dashboard-stat-revenue', 'Revenue by month', [
+                dataTable('dashboard-stat-revenue-table', SampleBindingName.RevenueByMonth, widgetTableOptions, revenueColumns),
+            ]),
+            page('dashboard-stat-flight', 'In flight', [
+                observableDataTable('dashboard-stat-flight-table', SampleBindingName.InvoicesInFlight, widgetTableOptions, invoiceColumns),
+            ]),
+            page('dashboard-stat-tickets', 'Open tickets', [
+                dataTable('dashboard-stat-tickets-table', SampleBindingName.OpenTickets, widgetTableOptions, ticketColumns),
+            ]),
+        ],
+        [TemplateSlotName.Primary]: [
+            page('dashboard-invoices', 'Recent invoices', [
+                dataTable('dashboard-invoices-table', SampleBindingName.AllInvoices, invoiceTableOptions, invoiceColumns),
+            ]),
+        ],
+        [TemplateSlotName.Secondary]: [
+            page('dashboard-adjustments', 'Adjustments', [
+                dataTable('dashboard-adjustments-table', SampleBindingName.AllAdjustments, widgetTableOptions, adjustmentColumns),
+            ]),
+        ],
+    },
+    displayName: 'Dashboard page',
+    description: 'A row of query-backed widgets over a wide and a narrow column, each bound to its own query.',
+};
+
+/** The two workspace-shaped templates. */
+export const workspaceTemplates: ScreenTemplate[] = [masterDetailPageTemplate, dashboardPageTemplate];