@mhome/app-facade-protocol 1.128.0 → 1.129.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/contract/card-skins-v1.md +7 -2
- package/contract/dashboard-composition-v1.md +59 -0
- package/fixtures/card-skins/space.json +1 -1
- package/fixtures/dashboard/composition-packing.json +7137 -0
- package/fixtures/presentation/cases.json +6 -6
- package/manifest/app-facade.v1.json +11 -1
- package/manifest/authorization.v1.json +4 -1
- package/manifest/host-provision-targets.v1.json +1 -1
- package/manifest/hub-targets.v1.json +1 -1
- package/manifest/pod-targets.v1.json +1 -1
- package/manifest/routing.v1.json +1 -1
- package/manifest/targets.v1.json +1 -1
- package/package.json +1 -1
- package/protocol.json +4 -1
- package/schema/canvas-layout.v1.schema.json +155 -0
- package/schema/card-skin-package.v1.schema.json +2 -2
- package/schema/dashboard-composition.v1.schema.json +431 -0
|
@@ -65,8 +65,13 @@ Package caching does not install, select, upgrade, or grant additional device au
|
|
|
65
65
|
All platforms retain the renderer isolation requirement, including for cached files.
|
|
66
66
|
|
|
67
67
|
The publication service validates metadata and bytes, not JavaScript behavior.
|
|
68
|
-
The renderer contract
|
|
69
|
-
|
|
68
|
+
The renderer contract is `apiVersion: 2`. Renderers supply content in a
|
|
69
|
+
framework-owned surface, both standalone and embedded. The host owns background,
|
|
70
|
+
radius, clipping, menus, editing and composition dividers. A content root stays
|
|
71
|
+
transparent and uses the inherited foreground; the renderer may arrange its title,
|
|
72
|
+
values and controls without a reserved header. Each member receives its own grid
|
|
73
|
+
and measured content viewport. Whole-card API 1 packages are rejected and must be
|
|
74
|
+
adapted and rebuilt; there is no legacy rendering mode.
|
|
70
75
|
The authoring build verifies the bundled ESM structure; the browser host verifies
|
|
71
76
|
renderer exports against the manifest before using them. Each base owns its
|
|
72
77
|
presentation adapter and renderer host; common card state and actions do not
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
# Canvas layout and card composition
|
|
2
|
+
|
|
3
|
+
Canvas owns one versioned layout document for every Dashboard placement. Card
|
|
4
|
+
bodies own content, views, business references and size-only `defaultSizes`.
|
|
5
|
+
`cardIds`, absolute leaf positions and parent membership are read projections,
|
|
6
|
+
never independent stored placement authorities. Physical Device parentage does
|
|
7
|
+
not change this presentation model; arbitrary logical Cards can be composed.
|
|
8
|
+
|
|
9
|
+
The layout schema is `schema/canvas-layout.v1.schema.json`. Root coordinates are
|
|
10
|
+
Canvas-global; member coordinates are relative to their composition. Each item
|
|
11
|
+
has independent sm/md/lg layouts, limited to 2/4/6 columns respectively. Members
|
|
12
|
+
are leaf Card references, never nested compositions. IDs are unique and leaves
|
|
13
|
+
cannot be placed twice. Siblings cannot overlap; children must fit within their
|
|
14
|
+
outer rectangle. Coordinates use nonnegative signed-32-bit integers. The UTF-8
|
|
15
|
+
layout document is at most 256 KiB.
|
|
16
|
+
|
|
17
|
+
`/app/dashboard/canvas/content/get` returns all leaf definitions, `revision` and
|
|
18
|
+
`layoutDocument`. Observations remain independent and do not advance layout
|
|
19
|
+
revision. Opening the Dashboard or switching profiles never repacks a saved
|
|
20
|
+
layout. Default dimensions are used only when creating a placement.
|
|
21
|
+
|
|
22
|
+
## Commands
|
|
23
|
+
|
|
24
|
+
All three composition commands require current-Space write authorization and
|
|
25
|
+
`expectedRevision`. They return `{spaceId, canvasId, revision, layoutDocument}`;
|
|
26
|
+
creation also returns `createdItemId`. The backend owns validation and the whole
|
|
27
|
+
operation. A stale revision changes nothing. An optional `rootDrafts` array includes unsaved root placement changes for up to
|
|
28
|
+
three distinct profiles in that same commit. `rootDraft` remains supported for a
|
|
29
|
+
single profile; the two fields are mutually exclusive. Ordinary layout updates
|
|
30
|
+
may include `rootDrafts` for profiles other than their main `layoutSize`; organize
|
|
31
|
+
may include all edited profiles before arranging its selected profile.
|
|
32
|
+
|
|
33
|
+
- `/app/dashboard/canvas/composition/create`: `itemIds` selects two or more roots.
|
|
34
|
+
Existing compositions flatten to leaves; leaf identities and current dimensions
|
|
35
|
+
remain. Fixed-pass first-fit packing compares original, area, height and width
|
|
36
|
+
order across available widths. Choose smaller bounding area, then greater
|
|
37
|
+
width, with deterministic ties. No rotations, resizing or optimality guarantee.
|
|
38
|
+
Place the resulting outer rectangle near the selection without moving others.
|
|
39
|
+
- `/app/dashboard/canvas/composition/ungroup`: `compositionId` expands members
|
|
40
|
+
at outer-position plus local-position in every profile, preserving current size.
|
|
41
|
+
- `/app/dashboard/canvas/composition/layout/update`: `compositionId`, `layoutSize`
|
|
42
|
+
and all `members` replace that profile's local layout. Alternatively `reset:true`
|
|
43
|
+
repacks within current outer width and height. Omit `members` when resetting.
|
|
44
|
+
|
|
45
|
+
Ordinary drag, resize and organize also save Canvas layout and advance revision.
|
|
46
|
+
Organize treats a composition as one root, keeping its internal layout intact.
|
|
47
|
+
Group copy creates fresh container and Card IDs while retaining business refs;
|
|
48
|
+
move preserves member identity and internal layout. Cross-Canvas move commits
|
|
49
|
+
source and target Canvas documents together. Delete and resource cleanup prune
|
|
50
|
+
leaf references: one surviving member becomes an independent Card at its current
|
|
51
|
+
absolute position; zero members removes the container.
|
|
52
|
+
|
|
53
|
+
Existing data is converted explicitly with old writers stopped, a verified
|
|
54
|
+
backup and conflict checks. Runtime startup never converts legacy placement or
|
|
55
|
+
silently deletes a database. Cloud Canvas records stay in the existing `canvas`
|
|
56
|
+
table with unchanged primary keys. Existing records require an explicit in-place
|
|
57
|
+
conversion and a verified backup before cutover. Aliyun must have local
|
|
58
|
+
transactions enabled on that table; existing tables without the feature require
|
|
59
|
+
provider support. No replacement Canvas table is introduced.
|