ALTER PAGE limitations and syntax inconsistencies cause excessive trial-and-error

[engalar]

Summary

During a session fixing Workflow-related page errors and wiring up navigation, roughly 40% of interactions were wasted on syntax trial-and-error due to parser limitations, inconsistent syntax, and documentation mismatches. This issue consolidates the findings.

1. ALTER PAGE REPLACE cannot resolve page parameters

Repro:

-- Page has: Params: { $Entity: System.SomeEntity }
ALTER PAGE Mod.MyPage {
  REPLACE oldDataView WITH {
    DATAVIEW newDv (DataSource: $Entity) { ... }
  }
};

Error: failed to build datasource: parameter not found: $Entity

Workaround: CREATE OR REPLACE PAGE to rebuild the entire page — increases risk of regressions and drops properties that MDL doesn't model (e.g., IMAGE ImageUrl).

Expected: REPLACE should resolve page-level Params when building replacement widgets.

2. ALTER PAGE INSERT + SELECTION DataSource fails

Repro:

ALTER PAGE Mod.MyPage {
  INSERT AFTER myDataGrid {
    DATAVIEW dvSel (DataSource: SELECTION myDataGrid) { ... }
  }
};

Error: widget not found for selection: myDataGrid

Expected: Inserted widgets should be able to reference sibling widgets for SELECTION binding.

3. SNIPPETCALL Params not supported in ALTER context

Repro:

ALTER PAGE Mod.MyPage {
  REPLACE someWidget WITH {
    SNIPPETCALL sc (Snippet: Mod.MySnippet, Params: {Key: $value})
  }
};

Error: mismatched input 'Params'

Works fine in CREATE PAGE context. Parser should accept Params in ALTER as well.

4. Syntax inconsistencies across contexts

Context	Parameter separator	Example
CALL MICROFLOW	=	CALL MICROFLOW Mod.MF(Param = $val)
SHOW PAGE	:	SHOW PAGE Mod.Page(Param: $val)
Page widget Action: MICROFLOW	:	Action: MICROFLOW Mod.MF(Param: $val)
Page widget Action: keyword	MICROFLOW	Not CALL_MICROFLOW (different from microflow body)

Using = where : is expected (or vice versa) silently fails with a cryptic parser error. Either unify the separator or produce a clear error message like: expected ':' but found '=' — use ':' for page parameters.

5. Skill documentation vs actual syntax: Association

The mdl-entities.md skill documents:

CREATE ASSOCIATION Mod.Name (
  PARENT Mod.ParentEntity,
  CHILD Mod.ChildEntity
);

Actual mxcli syntax (from DESCRIBE ASSOCIATION):

CREATE ASSOCIATION Mod.Name
FROM Mod.ChildEntity TO Mod.ParentEntity
TYPE Reference
OWNER Default;

The PARENT/CHILD form produces a parse error. Documentation should match the parser.

6. Unsupported Workflow activities

These platform activities render as -- Unsupported action type in DESCRIBE and cannot be created:

Activity	Use case
GetWorkflowActivityRecordsAction	Retrieve activity history for a workflow
GetWorkflowDataAction	Get context object from a workflow
GetWorkflowAction (context → workflow)	Find workflow(s) for a given context object

For Workflow-heavy projects, every microflow touching these activities requires a placeholder + manual Studio Pro completion. This is the single biggest capability gap.

Impact

• ~11 wasted round-trips in a single session
• Every Workflow-related microflow requires Studio Pro manual completion
• ALTER PAGE is often unusable for targeted edits, forcing full page rebuilds

Suggested priorities

1. Support Workflow activities — highest impact for Workflow projects
2. ALTER PAGE parameter context — REPLACE/INSERT should resolve page params
3. Unify parameter separators or improve error messages
4. Align skill documentation with actual parser syntax

[github-actions]

Issue Triage

Summary:
The issue describes several problems with ALTER PAGE handling, parameter syntax inconsistencies, documentation mismatches, and missing support for Workflow activities in mxcli.

Checklist of required information (bug report)

Required info	Present?	Notes
mxcli version (output of mxcli --version or commit/build)	❌	Not mentioned
Mendix version of the project being processed	❌	Not mentioned
Scenario – what the user was trying to do (MDL script, CLI command, etc.)	⚠️ Partially	The issue shows example MDL snippets, but does not state the exact CLI command or context in which they were run.
Expected output – what should have happened	✅	Each subsection includes an “Expected” statement.
Experienced output – what actually happened (error message, wrong result, crash)	✅	Each subsection includes an “Error” statement.
AI bug report – output of mxcli diag --bundle or at least the session log	❌	Not provided

What’s missing / needed
To properly investigate, please add:

1. The exact version of mxcli you are using (mxcli --version).
2. The Mendix version of the .mpr project you are editing.
3. The full CLI command you ran (e.g., mxcli apply -f script.mdl) and any relevant environment details.
4. If possible, run mxcli diag --bundle and attach the resulting archive, or at least paste the session log that shows the commands and errors.

Once those details are supplied, we’ll be able to reproduce the issues and work on fixes. Thank you for taking the time to report these problems!

---

Automated triage via OpenRouter — workflow source