Modularize the export layer: node types declare their export composers — no compiled type gates #1576

Activity

1. rbuergi commented on Aug 21, 2026

   

   rbuergi

   on Aug 21, 2026

   ContributorAuthor

   More actions

   Verdict: PARTLY DONE on main → finished by the two PRs below

   Verified against origin/main (not PR titles). Phase 1 (#1594) landed the declaration and the one generic menu provider. Three compiled type gates survived it, and the acceptance list's item 4 was still open:

   item	on main today
   1. config.WithExportComposer(descriptor)	shipped as WithExport(ExportDeclaration) — src/MeshWeaver.Graph/ExportDeclaration.cs	✅
   2. ONE generic menu provider; per-type providers deleted	ExportMenuProvider; MarkdownExportMenuProvider/DeckExportMenuProvider gone	✅
   3. templates dispatch through the declared composer	❌ ExportPdf.csx:74 / ExportHtml.csx:67 still DeckNodeType.Matches(rootNode.NodeType)	✗
   4. the bridge's suffix gates deleted	❌ ExportDeclaration.Resolve still carried the DeckNodeType.Matches fallback; Publish/Deck declared nothing, so the fallback was load-bearing	✗

   Note the export engine LEFT this repo in 0b3b4266f ("Fourteen modules leave the platform") — MeshWeaver.Markdown.Export now lives in MeshWeaver.Plugins, so items 3 and 4 are a two-repo change.

   PRs

   • Systemorph/MeshWeaver.Plugins#553 — items 3 + the declaration. Publish/Deck DECLARES .WithExport(ExportDeclaration.SlideDeck); ExportMenuProvider and ExportDocumentLayoutArea read Configuration.Get<ExportDeclaration>(); the templates dispatch on a composition input. Green.
   • refactor(export): delete the export layer's last compiled type gate (#1576 item 4) #1973 — item 4: ExportDeclaration.Resolve deleted (no callers left), plus the doc and a contract test.

   How the declaration reaches a template

   The design note said "put the composition on the export request, stamped by ExportDocumentLayoutArea". It turned out simpler: ExportDocumentHandler runs ON the source node's own hub — every caller targets new Address(sourcePath) — so it reads the declaration off hub.Configuration, the same read the menu provider does, and stamps it into the script inputs. No contract change, no client change, and the layout area never has to hand a value forward.

   The gate's failure mode, reproduced

   A plugin type that composes like a deck but is not NAMED one fell through to the document branch and exported the root node's own body. A deck-shaped node has no body, so the export succeeded and produced an empty file. Control run of the new test against the pre-fix module code:

   activity status=Succeeded
     [Information] Rendered 414 bytes of email-safe HTML
   === TEST FAILED: Expected "<!doctype html>…<div style="max-width:840px;…"></div></body></html>"
       to contain "ALPHAWIDGET" …
   Failed: 1
   

   One gate deliberately NOT removed

   DeckSelection.ResolveDeckSelection keeps SlideNodeType.Matches for the DEFAULT slide query. That is not an export composer — it is which children a deck with no manifest treats as slides, and it is already overridable as data (DeckContent.Query, which turns the filter off entirely). Leaving it does not let a name gate back into the export path.

   Merge order: Plugins#553 first, then #1973 — the fallback is what keeps a deck exportable on an install whose Publish pack has not yet synced its declaration.
2. rbuergi

   added a commit that references this issue on Aug 21, 2026

   Merge pull request #1973 from Systemorph/chore/ws7-finish

   ...

   6031e69
3. rbuergi commented on Aug 25, 2026

   

   rbuergi

   on Aug 25, 2026

   ContributorAuthor

   More actions

   Fixed on origin/main — verified rather than assumed.

   ExportDeclaration (src/MeshWeaver.Graph/ExportDeclaration.cs:41) is the declaration, set via config.WithExport(...). Commit e2cba48723 collapsed DeckExportMenuProvider + MarkdownExportMenuProvider into a single ExportMenuProvider (now MeshWeaver.Plugins:src/MeshWeaver.Markdown.Export/Layout/ExportMenuProvider.cs, registered in MarkdownExportExtensions.cs), and d50050cb13 deleted the last compiled type gate — item 4 — including the DeckNodeType.Matches transition fallback. isDeck has zero occurrences tree-wide; templates now dispatch on the composition stamped by ExportDocumentHandler.

   Crucially — extracting is not using, so the consumer is named and pinned: Publish/Deck declares WithExport(ExportDeclaration.SlideDeck), asserted by Plugins:Publish/Deck/Test/DeckTests.cs and DeclaredCompositionExportTest.

   The residual SlideNodeType.Matches/DeckNodeType.Matches callers (DeckSlidesCache.cs:204, MarkdownFileParser.cs:270) are deck ordering and the persistence parser — #1580's scope, not the export layer's.
4. rbuergi

   closed this as completedon Aug 25, 2026