Fix #834 (ALTER PAGE into a customContent column) + two defects found with it

[ako]

Follow-on to #115, which merged before these three commits existed. Fixes upstream #834 plus two independent defects found while verifying it.

Verified against mxbuild 11.6.6 throughout.

mendixlabs#834 — ALTER PAGE could not reach a widget in a customContent column

alter page … set <prop> on <widget> reported widget "X" not found when the widget sat inside a datagrid column rendered as customContent. The only remedy was CREATE OR REPLACE PAGE — a full page rewrite.

findInWidgetChildren's pluggable branch searched the grid's own Object.Properties[].Value.Widgets and matched columns by derived name, but never descended into a column's own content. Columns live at Object.Properties[columns].Value.Objects[]; a column's widgets are one level deeper, at Properties[content].Value.Widgets[].

Addressing is by the nested widget's own name — not the grid.column.widget path the issue asks for. DataGrid2 columns carry no stored name in the MPR (the existing findBsonColumn documents this, and the BSON confirms it: the grid is a pluggable widget, so columns are WidgetObject entries with no Name). A column segment could therefore only ever be a derived name — the bound attribute, or the caption — which goes stale the moment someone edits the caption. The nested widget's name is real and stable, so on btnEdit works directly and the grammar needs no change.

A second test pins that a column still resolves by its derived name: the new descent runs in the same loop and could otherwise shadow it.

Two defects found while verifying

set Caption failed on every action button. With the widget found, the set still failed — widget has no Caption property. Checked whether that was specific to nesting: it wasn't. It reproduces on a plain top-level button too. An ActionButton has no Caption document; its caption is a Forms$ClientTemplate under CaptionTemplate (Template → Items[] → Translation.Text), which is the same structure setWidgetContentMut already walked for Content. Both setters now share a helper.

Committed separately, since it's independent of mendixlabs#834 — and the finder fix alone would not have made the reporter's command work.

describe invented an else on a type split. Left as a known artifact in #115; now fixed. An object-type decision always carries an (empty) outgoing flow — the null-object case — which the builder emits whether or not an else was written. DESCRIBE rendered it as a bare else, so describing a split written without one produced MDL with an else, and each describe→exec pass accumulated another.

Fixed in the describer (drop the else line when its body renders empty, the same pattern the if/else emitters already use), not the builder. The obvious builder fix — don't emit the branch when no else is written — was implemented first and is wrong: without that flow the build fails CE0089 "The '(empty)' value should be configured for an outgoing flow." It's load-bearing, and MDL's else on an inheritance split is that (empty) case. That also retro-explains a result from #115: else can't substitute for the base entity's case (CE0090) because (empty) and the base type cover different things.

Worth recording how the wrong fix was caught — every shape was re-run through mxbuild, not just the test suite. The unit tests passed against it; the type splits it broke only failed at build time.

Verification

	before	after
on btnEdit (nested in customContent)	widget not found	Caption: 'Changed'
on btnTop (top-level button)	no Caption property	Caption: 'Changed too'
describe of a split with no else	prints else	prints none
mxbuild 11.6.6	—	0 errors

• Full go test ./... green; make check-mdl and check-skill-mdl pass.
• describe→exec→describe is byte-stable for an empty-branch split, an all-branches-return split, and an authored else.
• The describe fix was confirmed to fail with the exact symptom when reverted.
• Re-verified after merging the latest main (which moved twice while this was in flight).

Note for review

I deliberately did not add the 3-segment grid.column.widget grammar the issue requests — reasoning above. If ambiguity ever bites (two columns with same-named children), the better answer is an ambiguity error like the one columnMatchCount already produces, rather than a path built on a name that isn't stable. Worth saying so on the issue when it's closed.

🤖 Generated with Claude Code

https://claude.ai/code/session_013uQvFDd5R4eNqqita59jM8

---

Generated by Claude Code