| | |
| | | legacy `merge` / `readMergedLayoutConfig` untouched. |
| | | *(Optional: add a baukasten test-case folder under `data/test/json` and run `npm run debug:json-merge`.)* |
| | | |
| | | ## To do (suggested order) |
| | | |
| | | ### Runtime |
| | | - [x] **B. Merged-config endpoint.** Additive baukasten branch in `WebUIController.readLayoutConfig` |
| | | (`webuiProject === "baukasten"` → `BaukastenService.readConfigurations(refs)` → |
| | |
| | | `clientDir/index.html` when `webuiProject === "baukasten"`; `getReadFilePath` resolves |
| | | `/webui-content/{token}/t/baukasten/…` assets under `clientDir` (with a traversal guard). |
| | | Reuses the existing routes; path-only `style/*` + `tokenWorker.js` unchanged (per-customer). |
| | | |
| | | |
| | | ### Supporting |
| | | - [x] **E. Real configuration data (starter).** Added a real `14243/public/layout1.json` (root |
| | |
| | | `baukasten` project (so it had been 500-ing). The client already applies it via the shared |
| | | `TemplateLoaderService` (`construction:initialize` → fetch `themeConfig` → `:root` color vars + |
| | | `template`/`config-id` options), so no client change. *(Server-only JS — furnplan_web reload.)* |
| | | *(Follow-up implemented in M2.)* |
| | | *(Follow-up implemented in M2. Later superseded for baukasten by **T**: the runtime theme now rides in |
| | | `layout.json` via `construction:initialize`, and `readThemeConfig` is the AUC-editor source only.)* |
| | | - [x] **M2. AUC theme editor for baukasten.** Restructured `article-url-configurator.ts` |
| | | `onWebUIModeDropDownChanged` so the `themeConfig` fetch + `buildWebUIThemeConfig` run once for every |
| | | webui project incl. baukasten (removing the baukasten early-return / code duplication). Baukasten now |
| | | shows the theme editor (`#webUIThemeOptions`), so `webui_theme_config` is UI-editable and round-trips |
| | | via the existing `getWebUIThemeConfigJson`/`prepareSave` path; category filters stay modular-only. |
| | | Together with M this gives baukasten full per-customer theming parity. *(AUC rebuild — user's build.)* |
| | | *(Per-layout theming was explored afterwards and shelved — see **T** under "Shelved / parked".)* |
| | | *(Per-layout theming was explored afterwards; initially shelved, later **shipped** — see **T**.)* |
| | | - [x] **N. Move `client_logic` into the baukasten monorepo.** Relocated the Vite client source into |
| | | `baukasten/apps/client` (new `apps/` workspace glob; package `@dh-software/baukasten-client`), registered |
| | | in `package.json` + `pnpm-workspace.yaml` (added `autoInstallPeers` + the client's dev-link `overrides`, |
| | |
| | | `baukasten-data/`) was archived under `baukasten/old/`, now **deleted** after verification. *(Done.)* |
| | | - [x] **Q. Test real layout 1 & 2 configurations & fix bugs.** Real layout_1 & layout_2 configs load and |
| | | render correctly on the baukasten base (light-DOM adapter + merge graft, full UI). Verified working. |
| | | - [ ] **R. `fv-layout`: rework the component CSS.** Revisit the `:host` / `.layout-container` / `.node` |
| | | styling, possibly dropping the inner `.layout-container` wrapper so the grid lives directly on the |
| | | host (simpler tree, fewer wrappers). |
| | | - [x] **R. `fv-layout`: rework the component CSS.** **User-owned** — implementing + committing directly. |
| | | Revisit the `:host` / `.layout-container` / `.node` styling, possibly dropping the inner |
| | | `.layout-container` wrapper so the grid lives directly on the host (simpler tree, fewer wrappers). |
| | | - [x] **G. End-to-end verification** — pick + order → save → reopen (restored) → open link → client loads, |
| | | fetches merged config, renders. Verified. *(Save-As parity broke out as **G2** — decided: kept as-is.)* |
| | | - [x] **G2. Save-As / Template-As parity — decided: keep as-is.** Save-As/Template-As |
| | |
| | | *consistent* with the pre-existing modular Save-As, not a regression. **Left unchanged.** If ever fixed, |
| | | fix both together: carry the top-level fields through the Save-As handlers → `UseCaseConfigurationModel.create` |
| | | body → the server `create` template. (Normal *Save* works — it PUTs the whole `openedConfiguration` to `update`.) |
| | | - [ ] **H. Packaging / release** — publish `@dh-software/baukasten` + `@dh-software/baukasten-config-ui` |
| | | to `npm.furnco.de` (replace the `file:` deps); propagate the `furncloud-models` schema change; |
| | | mirror all furnplan_web/furncloud-models edits into the released `_furnview` bundle. |
| | | - [x] **H. Packaging / release** — `@dh-software/baukasten` + `@dh-software/baukasten-config-ui` (+ types / |
| | | config-reader / permissions) **published to `npm.furnco.de`**. Follow-ups that ride on the publish (do |
| | | when needed): swap furnplan_web's two `file:` deps → published `^` ranges; commit + push the |
| | | `furncloud-models` `baukastenConfigurations` schema edit and re-pin furnplan_web to it; mirror the |
| | | furnplan_web/furncloud-models edits + the baukasten client/configs into the `_furnview` bundle. |
| | | |
| | | ### Per-layout theme — SHIPPED |
| | | - [x] **T. Per-layout theme config.** Implemented via the previously-preferred-but-shelved approach (3): |
| | | **the theme rides in `layout.json` and the client applies it.** `template.service` (webui-core) now takes |
| | | the theme from the `construction:initialize` event payload (the merged `config/layout.json`, which embeds |
| | | `layout.theme`) instead of a separate `themeConfig` fetch, and `WebUIController.readLayoutConfig`'s |
| | | baukasten branch bakes per-customer overrides into it — |
| | | `layout.theme = _.merge(layout.theme, JSON.parse(configuration.webui_theme_config))`, guarded **inside |
| | | `if (layout)`** so it never derefs an undefined merge result (empty `baukastenConfigurations` / service |
| | | not ready → `readMergedBaukastenConfig` returns `undefined`), with the `JSON.parse` in its own try/catch. |
| | | `readThemeConfig` is now the **AUC-editor's source only**: its `getConfiguration(req, false)` moved inside |
| | | a `try/catch` (fixes the earlier server crash on the no-`a` theme fetch) and it returns the raw |
| | | `layout.theme` — the editor merges `webui_theme_config` client-side in `buildWebUIThemeConfig`. The empty |
| | | fallback `{colors:{},template:{}}` is intentional (base theme defaults removed from the dist configs). |
| | | Modular configs (no embedded `theme`) still fall back to the separate `themeConfig` fetch, so legacy |
| | | theming is unaffected. Supersedes M's "client fetches `themeConfig`" note for baukasten. |
| | | *(webui-core `template.service` change = user's build/publish; server JS = furnplan_web reload.)* |
| | | |
| | | ## To do (suggested order) |
| | | |
| | | ### Future / large |
| | | - [ ] **I. Baukasten "configurator"** — tool/UI to generate & edit customer `fileinfo.json` + config |
| | | JSONs (so DAs don't hand-edit files). |
| | | JSONs (so DAs don't hand-edit files). **Direction (concrete sub-tasks TBD together):** extract & rework |
| | | the *necessary* parts of the current AUC into separate packages — consumed by the AUC itself for now — |
| | | that the Baukasten configurator then reuses to configure the existing AUC settings from the Baukasten UI, |
| | | cleaned up to be understandable by an end-user. |
| | | - [ ] **J. Retire the old DB-backed 3-layer system** once Baukasten fully replaces it (migration/cleanup). |
| | | - [ ] restructure furnview-components into: |
| | | 1. legacy-components (components that have been entirely replaced by others) |
| | | 2. furnview-components (current components with styleVars and no dh-components internals) |
| | | 3. baukasten-components (prefix bk-, fv-components that are reworked to use dh-components and no longer support stylevars, styled using material design 3) |
| | | - [ ] **S. Revisit `isStoreMember` after the global store-system rework.** The current resolver reads |
| | | `FurncloudCredential.StoreTree.Stores[].kdnr_dh`; once the planned global rework of the |
| | | store/membership model lands, re-align it to the new shape/semantics. |
| | | |
| | | ### Shelved / parked |
| | | - [ ] **T. Per-layout theme config (SHELVED).** The theme schema (`theme.json`) was per-layout historically |
| | | (`bin_layout_1/config` vs `bin_layout_2/config`), but baukasten has one shared client folder, so M's |
| | | shared `clientDir/config/theme.json` can't serve both. No *easy, self-contained* approach was found, so |
| | | it's parked. **Interim: M stands** — runtime + AUC editor both use the single shared `theme.json`, which |
| | | is fine while layout_1/layout_2 themes are effectively identical (they are today); revisit when they truly |
| | | diverge, or fold into **N** (moving `client_logic` into the monorepo may make a client-side approach |
| | | self-contained). Approaches considered & rejected: (1) `readThemeConfig` re-reads the base config's |
| | | `theme` — fragile config re-read + base-first assumption; (2) full merge in `readThemeConfig` + shared |
| | | helper + `readLayoutConfig` strip + AUC `?a=<id>` — too many changes; (3) theme rides in `layout.json`, |
| | | client applies it — cleanest, but spreads across two published webui-core packages (`webui-api`: |
| | | `event/events.ts`, `service/template.service.ts`; `webui-configuration-parser`: |
| | | `types/construction.types.ts`, `service/construction.service.ts`) + a `webui_theme_config` bake-in in |
| | | `readLayoutConfig`, needing a webui-core build/publish + client rebuild. Key facts for the revisit: the |
| | | merge preserves an embedded top-level `theme`; `getConfiguration` needs `?a=` (the AUC theme fetch lacks |
| | | it); the AUC editor merges `webui_theme_config` client-side while the runtime does it server-side; |
| | | `client_logic` consumes webui-core as versioned deps. |