fix: support named datasource mappings for multi-source widgets

[tjorim]

Closes #1109

Follow-up to #643. That issue eliminated silent data loss by rejecting named datasource values and retaining a generic DataSource workaround; this PR safely implements the deferred general capability.

What changes

• Resolves a datasource by its declared mapping key or alias before the generic fallback.
• Allows real datasource expressions in named datasource properties, while rejecting scalar lookalikes.
• Activates datasource-dependent modes from the mappings belonging to that mode.
• Preserves independent entity context for datasource-bound properties.
• Emits named datasource keys from DESCRIBE PAGE when a generic DataSource clause would lose identity.
• Prevents the generic fallback from copying one datasource into every slot of a multi-source mode.
• Preserves unsupported named datasource values as an explanatory DESCRIBE comment.

The generic DataSource form remains backward-compatible for a single-datasource mode.

Validation

• make build, make test, make lint, and make check-findings passed on the final rebased branch.
• Regression and unit coverage cover named datasource mode selection, scalar alias rejection, distinct multi-source mappings, unsupported-source describe output, and round-trip MDL parsing.
• Public ComboBox fixture executed successfully.
• Tested with Mendix 11.12.3 on a disposable project copy: mxcli docker check --no-update-widgets reported 0 errors.

Agentic use

The custom-widget skill documents the neutral multi-source pattern, and the regression fixtures avoid application-specific schemas.

[github-actions]

AI Code Review

Critical Issues

• None found.

Moderate Issues

• None found.

Minor Issues

• None found.

What Looks Good

• The PR correctly implements named datasource support for multi-source widgets, resolving the silent data loss issue from Datasource-typed pluggable-widget property passes 'check' but is silently dropped at 'exec' (CE0642) #643.
• Changes are minimal and focused: executor logic for mapping resolution, DESCRIBE output preservation, and validation updates.
• Comprehensive test coverage includes:
  • New bug test (mapping-1-named-widget-datasources.mdl) demonstrating the fix
  • Unit tests for named datasource value resolution, alias handling, multi-source fallback suppression, and DESCRIBE roundtrip
  • Extended validation tests ensuring scalar lookalikes are rejected even under aliases while real datasource expressions pass
• Code quality improvements:
  • Extracted mappedWidgetPropertyNames helper to centralize mapped property tracking
  • Renamed and refactored anyCustomWidgetDataSource → namedCustomWidgetDataSources with clearer semantics
  • Case-insensitive property mapping checks for robustness
  • Proper restoration of currentModeDataSourceCount via defer statement
• DESCRIBE output now preserves named datasource keys for multi-source widgets, preventing loss of identity during roundtrip
• Validation correctly distinguishes real datasource expressions from scalar lookalikes using namedDataSourceValue helper
• Mode selection (hasDataSource condition) now checks named datasource mappings before falling back to generic datasource
• All changes maintain backward compatibility: single-datasource widgets still use generic DataSource: fallback

Recommendation

Approve the PR. The implementation fully addresses the issue, follows project patterns, includes adequate test coverage, and maintains backward compatibility while enabling the requested functionality. No changes are needed.

---

Automated review via OpenRouter (Nemotron Super 120B) — workflow source

[tjorim]

I want to record my disappointment with how this was handled.

I opened #1109 before implementation began, documented the intended behavior and validation, and linked a working fork PR. The parallel implementation that landed through #1117 covers substantially the same scope—its commit history even references #1109—yet there was no discussion of the existing implementation, no request to collaborate, and no acknowledgement of it.

That leaves this PR conflicted and largely redundant after significant investigation, implementation, tests, documentation, and Mendix validation. The repository’s CONTRIBUTING guide says the issue/approval/assignment workflow exists to prevent duplicate work; regardless of the missing human approval/assignment on #1109, this is precisely the outcome that process is meant to avoid.

Please clarify how contributors should avoid this in future, especially when an issue already contains a linked implementation or open PR.