mxcli version: main at 643271e8 (Mendix 11.12.1, MPR v2, macOS)
Summary
A DataGrid2 filters itself: each column takes a filter widget, and a column over an association takes a dropdown whose options are the associated objects. mxcli supports all of it. The documentation puts it where someone building a grid does not look, and leaves out the two forms a real list needs most, so the pattern that gets written instead is a hand-built filter bar.
Where the documentation sends the reader
create-page/reference/widgets.md opens its filter section with:
### Filter Widgets
Filter widgets are used inside GALLERY FILTER containers to enable search/filtering:
Everything after that — textfilter, numberfilter, datefilter, dropdownfilter, and the association form further down — is correct and applies to a data grid column just as well. But the section announces itself as being about galleries, so a reader working on a data grid stops at the first line.
overview-pages/SKILL.md, which is the page a reader building an overview list actually opens, has a table matching each attribute type to its filter widget, and stops there. It does not show:
- a
dropdownfilter over an association (Association: + datasource: + CaptionAttribute:), which is what a list of orders needs to filter by customer;
FilterType: between, which turns a date column into a range;- any statement that the grid filters itself, so a filter bar of one's own is the wrong answer.
What gets written instead
Two apps generated with mxcli, by different models, independently built the same thing on their order list: a non-persistent "filter" entity, check boxes and a combo box bound to its attributes, an apply microflow on every OnChange, a Clear button, and an XPath on the grid reading the filter object back. One of them cost three microflows (66 lines of MDL), nine input widgets and 1,100 characters of XPath, where five column filters — one per column — do the same job and keep the grid's paging, sorting and per-user personalisation working.
One of those sessions read widgets.md six times while building the page.
Verified
On a blank 11.12.1 project, with the binary built from main at 643271e:
column colCreated (attribute: "Created", caption: 'Created') { datefilter fltCreated (FilterType: between) }mxcli check --references passes, exec applies it, mx check reports 0 errors, and DESCRIBE PAGE returns the same line. The association form round-trips the same way.
Fix
I have a branch that:
- rewrites the lead-in of the filter widgets section so it names both homes, the data grid column first, with a two-line example of each;
- adds to
overview-pages the association dropdownfilter, FilterType: between, and one short paragraph saying the grid filters itself and what the hand-built alternative costs (the skill stays under the 700-line bound: 675 → 696);
- adds a CHANGELOG entry under
[Unreleased].
Documentation only — no behaviour change. Full local run of push-test.yml is green, including check-skill-mdl.sh over .claude/skills/mendix and the integration tests against mx 11.12.1.
Happy to open the PR.
mxcli version: main at
643271e8(Mendix 11.12.1, MPR v2, macOS)Summary
A DataGrid2 filters itself: each column takes a filter widget, and a column over an association takes a dropdown whose options are the associated objects. mxcli supports all of it. The documentation puts it where someone building a grid does not look, and leaves out the two forms a real list needs most, so the pattern that gets written instead is a hand-built filter bar.
Where the documentation sends the reader
create-page/reference/widgets.mdopens its filter section with:Everything after that —
textfilter,numberfilter,datefilter,dropdownfilter, and the association form further down — is correct and applies to a data grid column just as well. But the section announces itself as being about galleries, so a reader working on a data grid stops at the first line.overview-pages/SKILL.md, which is the page a reader building an overview list actually opens, has a table matching each attribute type to its filter widget, and stops there. It does not show:dropdownfilterover an association (Association:+datasource:+CaptionAttribute:), which is what a list of orders needs to filter by customer;FilterType: between, which turns a date column into a range;What gets written instead
Two apps generated with mxcli, by different models, independently built the same thing on their order list: a non-persistent "filter" entity, check boxes and a combo box bound to its attributes, an apply microflow on every
OnChange, a Clear button, and an XPath on the grid reading the filter object back. One of them cost three microflows (66 lines of MDL), nine input widgets and 1,100 characters of XPath, where five column filters — one per column — do the same job and keep the grid's paging, sorting and per-user personalisation working.One of those sessions read
widgets.mdsix times while building the page.Verified
On a blank 11.12.1 project, with the binary built from
mainat 643271e:mxcli check --referencespasses,execapplies it,mx checkreports 0 errors, andDESCRIBE PAGEreturns the same line. The association form round-trips the same way.Fix
I have a branch that:
overview-pagesthe associationdropdownfilter,FilterType: between, and one short paragraph saying the grid filters itself and what the hand-built alternative costs (the skill stays under the 700-line bound: 675 → 696);[Unreleased].Documentation only — no behaviour change. Full local run of
push-test.ymlis green, includingcheck-skill-mdl.shover.claude/skills/mendixand the integration tests againstmx11.12.1.Happy to open the PR.