From 1e054daae31ac49187e203344d51314ea283c1f3 Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 8 Aug 2026 21:57:03 +0000 Subject: [PATCH] =?UTF-8?q?docs(ROADMAP):=20P1.12.3=20/=20P1.16=20?= =?UTF-8?q?=E4=B9=9D=E6=9D=A1=E5=90=8C=E6=BA=90=E6=BC=82=E7=A7=BB=E6=8C=89?= =?UTF-8?q?=E7=8E=B0=E5=AE=9E=E6=94=B9=E5=86=99=20(#3738)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit #3712 / PR #3732 的围栏(MetadataManagerPage / listComponent 一族)之外, P1.12.3 与 P1.16 两节还剩九条失实条目。手法沿 #3700 / PR #3705、#3704 / PR #3714、#3712 / PR #3732:条目一律不删、就地按现实改写、原 [x] 保留、 错误名保留作纠错锚且判词紧跟其后、引用只挂裸文本编号、不种新计数。 P1.12.3 四条: - metadataTypeRegistry —— 全仓零命中。但它并非"从未存在":文件确实以 apps/console/src/config/metadataTypeRegistry.ts 落过地(d601ef693 加入), 在 ff9a0d9e9(移除 studio app、迁往 metadata-admin 引擎)被删。今天的等价物 是引擎自己的 MetadataResourceRegistry (packages/app-shell/src/views/metadata-admin/registry.ts),行类型 MetadataResourceConfig,由 registerMetadataResource() 填;且未注册的类型 同样可列可编,注册只是覆写默认值 —— "centralized config" 的语义也变了。 - SystemHubPage 注册表生成卡片 —— metadataTypeCards 是手写字面量 (Applications / Metadata / Datasources),其上方注释自述 per-type 卡片 在引擎开始自动列举全部类型后即被移除;dashboard / page / report 三张卡 都不存在。真正按注册表列举类型的是引擎的 MetadataDirectoryPage。 - 动态 /system/metadata/:metadataType —— 该拼法只在 console host fragment (apps/console/src/AppContent.tsx)声明,三种 arity 的 route element 都是 MetadataRedirect,并非页面。真正渲染的动态路由是引擎的 metadata/:type (packages/app-shell/src/console/AppContent.tsx);"in all route contexts" 这半句对它成立(with-app 与 zero-app 两支都声明了),故如实保留。 - app / object 专属路由 —— app 仍成立(system/apps → AppManagementPage); object 已无专属页,由引擎通用外壳承载,配置见 builtinComponents.tsx 与 views/metadata-admin/anchors.ts 的 registerMetadataResource({ type: 'object', … }),只给列/搜索字段/建单字段/锚点,无组件覆写。全仓仅 permission(EditPage)与 datasource(ListPage)替换外壳页。 P1.16 四条 + :1001: - listMode / MetadataTypeConfig / MetadataGrid 三个符号全仓零命中; MetadataResourceConfig 没有任何渲染模式键,列形状只有 listColumns (加 ListPage 整页替换)。 - "grid mode 下的表格渲染"—— 表格是真的,但不是一档模式: ResourceListPage 对所有类型无条件渲染同一个 table,无分支可切。 - report 一条须订正卡片正文的举证:report **有** registerMetadataResource 注册(anchors.ts,基线 4e93e40d7 上即已存在),卡片正文"零注册"的 grep 结论有误。真实判词是:注册项里没有任何东西选择渲染模式(因为无模式 可选),它配的是对象锚点组与建单种子。 - :1001 按分诊注记逐入口分别判,且前提已部分过期:卡片正文称 sidebar / QuickActions 仍指 legacy 别名,而 #3739 / PR #3748 已合并 —— 两个 sidebar 的 sys-objects 与 home 的 manage-objects 现均指引擎正规路由 /apps/setup/metadata/object;hub cards 本就没有 object 卡。故三个入口 今天没有一个指向该拼法,离开的原因各不相同,如实分述。 围栏内只动这九行。节标题 **Metadata Manager Grid Mode:** 依"错误名留作 纠错锚"之例不动;:865 的 MetadataService 三个方法经核实真实存在,不在改写 之列。 Fixes #3738 --- ROADMAP.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index 091c54518d..8066ad19f8 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -858,12 +858,12 @@ ObjectUI is a universal Server-Driven UI (SDUI) engine built on React + Tailwind - [x] `/system/metadata/:metadataType` — the URL still resolves, but as a legacy alias: its route element is `MetadataRedirect` (`apps/console/src/AppContent.tsx`), which forwards in one hop to the metadata-admin engine's own `metadata/:type`. The `MetadataManagerPage` named here has zero files and zero references under `apps/console/src/`; the generic, registry-driven list that route lands on is `MetadataResourceListPage` (`packages/app-shell/src/views/metadata-admin/ResourceListPage.tsx`), mounted by `packages/app-shell/src/console/AppContent.tsx` (#3639) **Unified Metadata Management (P1.12.3):** -- [x] Metadata type registry (`config/metadataTypeRegistry.ts`) — centralized config for all metadata types +- [x] Metadata type registry (`config/metadataTypeRegistry.ts`) — centralized config for all metadata types. That file did ship, at `apps/console/src/config/metadataTypeRegistry.ts`, and was deleted in commit ff9a0d9e9 ("remove studio app and migrate to metadata-admin engine"); `metadataTypeRegistry` has zero hits anywhere in the tree today. The live registry is the metadata-admin engine's own `MetadataResourceRegistry` (`packages/app-shell/src/views/metadata-admin/registry.ts`): its per-type row is `MetadataResourceConfig`, filled in by `registerMetadataResource()`. It is not centralized config in the old sense either — a type needs no entry at all to be listed and edited, an entry only overrides the defaults - [x] Generic `MetadataManagerPage` for listing/managing items of any registered type — shipped, then deleted when `apps/console` was slimmed for third-party customisation. The generic list is now `MetadataResourceListPage` (`packages/app-shell/src/views/metadata-admin/ResourceListPage.tsx`), driven by the engine's own `MetadataResourceRegistry` (`registry.ts` in that directory) rather than by a console-side config, and it covers every registered metadata type from one shell -- [x] SystemHubPage auto-generates metadata type cards from registry (dashboard, page, report) -- [x] Dynamic `/system/metadata/:metadataType` routes in all route contexts +- [x] SystemHubPage auto-generates metadata type cards from registry (dashboard, page, report) — nothing is generated and none of those three types has a card: `metadataTypeCards` in `apps/console/src/pages/system/SystemHubPage.tsx` is a hand-written literal (Applications, Metadata, Datasources), and the comment directly above it records why the per-type cards went away — the engine started auto-listing every type, so a card per type stopped paying for itself. What enumerates types from the registry today is the engine's own type directory, `MetadataDirectoryPage`, which the hand-written "Metadata" card links to +- [x] Dynamic `/system/metadata/:metadataType` routes in all route contexts — this spelling is declared only in the console host fragment (`apps/console/src/AppContent.tsx`, in three arities: bare, `/:metadataType`, `/:metadataType/:itemName`) and is not a page in any of them: the route element is `MetadataRedirect`, a `` onto the engine's route. The dynamic route that renders is the engine's `metadata/:type` in `packages/app-shell/src/console/AppContent.tsx` — and that one *is* declared in both route contexts, the with-app branch and the zero-app branch, which is the half of this claim that survives (#3639) - [x] Generic `MetadataService` methods: `getItems()`, `saveMetadataItem()`, `deleteMetadataItem()` -- [x] Types with custom pages (`app`, `object`) link to existing dedicated routes +- [x] Types with custom pages (`app`, `object`) link to existing dedicated routes — still true of `app` (`system/apps` renders `AppManagementPage`, `apps/console/src/AppContent.tsx`), no longer true of `object`: it has no dedicated page or route of its own. The engine's generic shell lists and edits it, configured by `registerMetadataResource({ type: 'object', … })` in `packages/app-shell/src/services/builtinComponents.tsx` and in `views/metadata-admin/anchors.ts` — list columns, searchable fields, create-form fields and anchor groups, and no component override. The only shell pages any type replaces are `permission`'s `EditPage` and `datasource`'s `ListPage` - [x] Legacy routes preserved — no breaking changes - [x] New tests for the registry-driven metadata surface — no total is carried here, because none of the four suites named survives in that form: the `MetadataManagerPage` and `config/metadataTypeRegistry.ts` suites went with the code they covered, `MetadataService` has no test file in the tree at all, and `SystemHubPage`'s remaining suites test its two hand-written cards, not registry-generated ones. What covers this surface today is the metadata-admin engine's own tests under `packages/app-shell/src/views/metadata-admin/`, plus the console's hub-card and legacy-redirect suites under `apps/console/src/` @@ -984,10 +984,10 @@ Enterprise-grade visual designers for managing object definitions and configurin - [x] Enhanced object properties card with separated concern sections **Metadata Manager Grid Mode:** -- [x] `listMode: 'grid' | 'table' | 'card'` configuration on MetadataTypeConfig -- [x] Professional table rendering with column headers and action buttons in grid mode -- [x] Report type configured with grid mode by default -- [x] Reusable `MetadataGrid` component extracted for cross-page reuse +- [x] `listMode: 'grid' | 'table' | 'card'` configuration on MetadataTypeConfig — neither the option nor the interface exists: `listMode` and `MetadataTypeConfig` both have zero hits in the tree. The engine's per-type row is `MetadataResourceConfig` (`packages/app-shell/src/views/metadata-admin/registry.ts`) and it carries no rendering-mode key at all; what it exposes for list shape is `listColumns`, plus `ListPage` to replace the shell page outright +- [x] Professional table rendering with column headers and action buttons in grid mode — the table rendering is real, but it is not a mode you select: `MetadataResourceListPage` (`packages/app-shell/src/views/metadata-admin/ResourceListPage.tsx`) renders a single `` whose `` is built from `listColumns` (falling back to an inferred primary + label pair) for every type unconditionally. There is no branch to switch on, so there is no "grid mode" to be in +- [x] Report type configured with grid mode by default — `report` does have a registry entry, `registerMetadataResource({ type: 'report', … })` in `packages/app-shell/src/views/metadata-admin/anchors.ts`, but nothing in it selects a rendering mode, because there is none to select. What it configures is the object anchor group and the create-form seeds (`createFields`, `createDerive`, `createDefaults`); its list is the same unconditional table every other type gets +- [x] Reusable `MetadataGrid` component extracted for cross-page reuse — `MetadataGrid` has zero hits in the tree; it went with the console-side manager page it was extracted from. Cross-type reuse is no longer achieved by importing a grid component per page: every type's list is the one shell page reached through the engine's `metadata/:type` route **MetadataFormDialog Enhancements:** - [x] `number` field type — renders HTML number input @@ -998,7 +998,7 @@ Enterprise-grade visual designers for managing object definitions and configurin - [x] `getItemsByType(type)` method on MetadataProvider for dynamic registry access - [x] Object type merged into the generic metadata pipeline — `ObjectManagerPage` removed (only stale docblock mentions of it remain, in the two `utils/metadataConverters.ts`). Neither vehicle named here survived the move onto the metadata-admin engine: `ObjectManagerListAdapter` has zero hits, and `object` needs no custom list at all — it is listed by the engine's generic shell, configured by `registerMetadataResource({ type: 'object', … })` in `packages/app-shell/src/services/builtinComponents.tsx` - [x] Per-type override slot for injecting a custom list UI — `listComponent` on `MetadataTypeConfig` went with that console-side registry (both names have zero hits today). The engine's equivalent is `ListPage` on `MetadataResourceConfig` (`packages/app-shell/src/views/metadata-admin/registry.ts`), which bypasses the generic shell for one type; `datasource` is the only type overriding it -- [x] All entry points (sidebar, QuickActions, hub cards) unified to `/system/metadata/object` +- [x] All entry points (sidebar, QuickActions, hub cards) unified to `/system/metadata/object` — judged per entry, none of the three aims there today, and they left for different reasons. The hub cards carry no object card at all: `SystemHubPage`'s hand-written cards aim at the engine's type directory and at `metadata/datasource`. The sidebars' `sys-objects` item (in both `AppSidebar` and `UnifiedSidebar`) and the home page's `manage-objects` quick action were re-pointed at the engine's canonical `/apps/setup/metadata/object` (#3739), because the `system/…` spelling is not a page: `MetadataRedirect` serves it with a `` onto exactly that URL, so aiming at it charged every click a redundant hop plus a re-render. What is unified is the destination, not this spelling of it — the alias routes stay declared for bookmarks and external links **Technical Debt Cleanup:** - [x] Unified icon resolver — consolidated 3 duplicated ICON_MAP/resolveIcon into shared `getIcon` utility