Environment: mxcli v0.24.0 (2026-09-24T05:44:35Z), same result on v0.23.0. Mendix 11.12.2. Widget: Mendix File Uploader 2.5.0. Fresh app from mxcli new App --version 11.12.2, macOS. Upstream main at d3adfa43 has no changes to cmd_pages_describe_parse.go / cmd_pages_describe_pluggable.go since v0.24.0.
Summary: describe page on a page with a File Uploader (uploadMode: 'files', associatedFiles set) prints the binding as a generic DataSource:. Executing that DESCRIBE output unchanged fails, because the builder refuses a generic datasource: clause on a widget whose schema declares two datasource properties. DESCRIBE → exec does not round-trip.
Steps to reproduce
- A page with a File Uploader authored by mxcli (for example
associatedFiles: association $currentObject/Uploads.Attachment_UploadRequest), mx check 0 errors.
mxcli -p App.mpr -c 'DESCRIBE PAGE Uploads."UploadRequest_NewEdit"' > roundtrip.mdl. The widget comes back as:
fileuploader upFiles (
DataSource: $currentObject/Uploads.Attachment_UploadRequest,
...
- On a copy of the app where the page differs (so exec does not short-circuit as
Unchanged page), run mxcli exec roundtrip.mdl -p App.mpr.
Actual
3 issues: 0 errors, 3 warnings, 0 info
Error: failed to build page: failed to build widget: widget `upFiles` (fileuploader) exposes 2 datasources, so a generic `datasource:` clause is ambiguous — name the one you mean: associatedFiles, associatedImages
Nothing is written (mx check stays at 0 errors), so this is a round-trip failure, not model damage.
Expected: DESCRIBE prints associatedFiles: association $currentObject/... (the key the builder accepts), and its output re-executes.
Cause (from reading main): the two sides decide on different counts. DESCRIBE (cmd_pages_describe_parse.go, the namedCustomWidgetDataSources switch) keeps the generic DataSource: clause when only one datasource is configured. The builder (widget_engine.go, the "declares %d datasource properties" check) rejects a generic clause when the widget's schema declares more than one. A File Uploader always has one configured (files or images) and two declared.
Suggested fixes, ranked
- DESCRIBE: emit the named key whenever the widget's schema declares more than one datasource property, even if only one is configured. Output for single-datasource widgets stays unchanged.
- Alternatively, builder: accept a generic
datasource: when exactly one of the declared datasource properties is visible/applicable under the widget's current configuration (uploadMode: 'files' makes associatedImages hidden).
Workaround: hand-edit the DESCRIBE output: DataSource: → associatedFiles:.
Retest: steps 1–3. Pass = exec builds the page and mx check says The app contains: 0 errors.
Related: #956 (named pluggable-widget action slots and the generic datasource fallback for this widget, closed).
Environment:
mxcli v0.24.0 (2026-09-24T05:44:35Z), same result onv0.23.0. Mendix 11.12.2. Widget: Mendix File Uploader 2.5.0. Fresh app frommxcli new App --version 11.12.2, macOS. Upstreammainatd3adfa43has no changes tocmd_pages_describe_parse.go/cmd_pages_describe_pluggable.gosince v0.24.0.Summary:
describe pageon a page with a File Uploader (uploadMode: 'files',associatedFilesset) prints the binding as a genericDataSource:. Executing that DESCRIBE output unchanged fails, because the builder refuses a genericdatasource:clause on a widget whose schema declares two datasource properties. DESCRIBE → exec does not round-trip.Steps to reproduce
associatedFiles: association $currentObject/Uploads.Attachment_UploadRequest),mx check0 errors.mxcli -p App.mpr -c 'DESCRIBE PAGE Uploads."UploadRequest_NewEdit"' > roundtrip.mdl. The widget comes back as:Unchanged page), runmxcli exec roundtrip.mdl -p App.mpr.Actual
Nothing is written (
mx checkstays at 0 errors), so this is a round-trip failure, not model damage.Expected: DESCRIBE prints
associatedFiles: association $currentObject/...(the key the builder accepts), and its output re-executes.Cause (from reading
main): the two sides decide on different counts. DESCRIBE (cmd_pages_describe_parse.go, thenamedCustomWidgetDataSourcesswitch) keeps the genericDataSource:clause when only one datasource is configured. The builder (widget_engine.go, the "declares %d datasource properties" check) rejects a generic clause when the widget's schema declares more than one. A File Uploader always has one configured (files or images) and two declared.Suggested fixes, ranked
datasource:when exactly one of the declared datasource properties is visible/applicable under the widget's current configuration (uploadMode: 'files'makesassociatedImageshidden).Workaround: hand-edit the DESCRIBE output:
DataSource:→associatedFiles:.Retest: steps 1–3. Pass = exec builds the page and
mx checksaysThe app contains: 0 errors.Related: #956 (named pluggable-widget action slots and the generic datasource fallback for this widget, closed).