Skip to content

Implement write support for expression, textTemplate, and selection pluggable widget property types in mxcli exec #1585

Closed

Description

@acarum

mxcli version: v0.26.0 (2026-10-11)
Mendix version: 11.12.4

Context:
mxcli widget describe correctly discovers all pluggable widget properties from the .mpk and reports their type. The MDL parser accepts them without errors.
However, mxcli exec does not persist all property types equally — some are silently dropped at write time.

What mxcli exec currently persists correctly:

┌──────────────────────┬─────────────────────────────────────┬───────────┐
│ Type │ Example │ Persisted │
├──────────────────────┼─────────────────────────────────────┼───────────┤
│ boolean │ Mode: true │ ✅ │
├──────────────────────┼─────────────────────────────────────┼───────────┤
│ enumeration │ FilterType: 'startsWith' │ ✅ │
├──────────────────────┼─────────────────────────────────────┼───────────┤
│ attribute │ AttributeToSearch: NId │ ✅ │
├──────────────────────┼─────────────────────────────────────┼───────────┤
│ datasource │ EntityDatasource: database from ... │ ✅ │
├──────────────────────┼─────────────────────────────────────┼───────────┤
│ action │ OnChange: call nanoflow ... │ ✅ │
├──────────────────────┼─────────────────────────────────────┼───────────┤
│ widgets (child slot) │ CustomContent { ... } │ ✅ │
└──────────────────────┴─────────────────────────────────────┴───────────┘

What mxcli exec does NOT persist:

┌──────────────┬───────────────────────────────────────┬───────────┐
│ Type │ Example │ Persisted │
├──────────────┼───────────────────────────────────────┼───────────┤
│ expression │ Placeholder: $currentObject/NId │ ❌ │
├──────────────┼───────────────────────────────────────┼───────────┤
│ expression │ SelectedObject: $currentObject/Id │ ❌ │
├──────────────┼───────────────────────────────────────┼───────────┤
│ textTemplate │ RequiredValidationMessage: 'Required' │ ❌ │
├──────────────┼───────────────────────────────────────┼───────────┤
│ selection │ selectionApi: MySelectionName │ ❌ │
└──────────────┴───────────────────────────────────────┴───────────┘

Observed behaviour:
The MDL parser accepts the properties without errors. During exec, the values are silently dropped with a warning. After exec, DESCRIBE PAGE does not include
them — as if they were never written. The model is left in a partial state with no indication of what is missing beyond the warning emitted at exec time.

Minimal reproduction:
mdl
mdl 1;
create or modify page MyModule.MyPage (
Layout: MyModule.MyLayout,
Params: ( $Obj: MyModule.MyEntity )
) {
dataview dv (DataSource: $Obj) {
pluggablewidget myWidget (
SomeExpressionProperty: $currentObject/MyAttribute,
SomeTextTemplate: 'This field is required',
SomeSelectionProperty: MySelectionName
)
}
};
Expected: all three properties written to the .mpr and visible in DESCRIBE PAGE.

Actual: a warning is emitted for each, all three values are dropped.

Impact:
step after exec, breaking the fully-automated pipeline and introducing a human error surface that scales with the number of pages migrated. There is currently
no way to detect which properties were silently dropped without re-opening every page in Studio Pro.

Request:
Implement persistence of expression, textTemplate, and selection pluggable widget property types in exec, consistent with how boolean, enumeration, attribute,
datasource, and action are already handled.

Activity

  1. github-actions commented on Oct 19, 2026

    @github-actions

    Issue Triage

    Summary:
    The issue requests that mxcli exec persist expression, textTemplate, and selection pluggable‑widget property types, which are currently dropped silently.

    Checklist (Feature Request)

    • ✅ Use case – explains why the feature is needed (prevents silent drops in automated pipelines).
    • ✅ Proposed syntax or behavior – implement persistence for those types, consistent with how boolean, enumeration, attribute, datasource, and action are handled.
    • ✅ Mendix version relevance – notes the Mendix version being used (11.12.4) and that the issue applies to that version.

    The issue appears complete. Thank you for the detailed report!


    Automated triage via OpenRouter — workflow source

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions