Skip to content

fix: emit correct enum value format for XPath vs expression contexts#167

Open
engalar wants to merge 1 commit intomendixlabs:mainfrom
engalar:fix/enum-value-context-syntax
Open

fix: emit correct enum value format for XPath vs expression contexts#167
engalar wants to merge 1 commit intomendixlabs:mainfrom
engalar:fix/enum-value-context-syntax

Conversation

@engalar
Copy link
Copy Markdown
Contributor

@engalar engalar commented Apr 10, 2026

Summary

  • XPath context (RETRIEVE WHERE): 3-part enum refs like Module.EnumName.Value now emit 'Value' (quoted value only) instead of the full qualified name
  • Expression context (CHANGE/CREATE): string literal enum values like 'Processing' are resolved to Module.EnumName.Processing when the attribute type is an enumeration (requires MPR context)
  • Same fix applied to page data source XPath handler (xpathExprToString)

Test plan

  • TestQualifiedNameToXPath_EnumValue — 3-part name → 'Value'
  • TestQualifiedNameToXPath_NonEnum — 2-part name passes through
  • TestExpressionToXPath_EnumInComparison — full WHERE clause roundtrip
  • TestExpressionToXPath_StringLiteralPreserved — string literals unchanged
  • TestExpressionToString_QualifiedNameUnchanged — expression context keeps qualified name
  • TestXPath_EnumValueReference — visitor XPath roundtrip (3 sub-tests)
  • Full go test ./mdl/... passes with 0 failures

Fixes #125

@github-actions
Copy link
Copy Markdown

AI Code Review

What Looks Good

  • Comprehensive test coverage: New test file cmd_microflows_helpers_test.go with 5 test functions covering enum value handling in XPath vs expression contexts, plus additional tests in visitor_xpath_test.go. All tests pass as reported.

  • Correct contextual handling: The fix properly distinguishes between XPath context (where 3-part enum refs like Module.Enum.Value should emit 'Value') and expression context (where string literals like 'Processing' should resolve to Module.EnumName.Processing for enum attributes).

  • Minimal, focused changes: The PR addresses exactly the issue described (Enum value syntax differs between XPath and expression contexts #125) without unnecessary modifications. Changes are confined to the relevant executor and visitor components.

  • Proper helper extraction: New functions (qualifiedNameToXPath, memberExpressionToString, lookupEnumRef) encapsulate the logic cleanly, making the code easier to understand and maintain.

  • Error handling: The lookupEnumRef function includes appropriate nil checks and gracefully falls back to standard behavior when the domain model isn't available.

  • Consistency: Both microflow actions (CreateObject/ChangeObject) and page data source XPath handling now use the same corrected logic.

  • No syntax changes: Since this fixes existing behavior rather than adding new MDL syntax, the syntax design and full-stack consistency checklist items don't apply (no grammar/AST/LSP changes needed).

Recommendation

The PR is ready to approve. It correctly resolves the enum value formatting issue in both XPath and expression contexts with appropriate test coverage and minimal, focused changes that maintain backward compatibility. No issues were found against the review checklist.


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

Enum values require different serialization depending on context:
- XPath (RETRIEVE WHERE): 'Value' (quoted value name only)
- Expression (CHANGE/CREATE): Module.EnumName.Value (qualified)

Fixes mendixlabs#125
@engalar engalar force-pushed the fix/enum-value-context-syntax branch from 5617638 to 9a450c2 Compare April 10, 2026 10:45
@github-actions
Copy link
Copy Markdown

AI Code Review

What Looks Good

The PR successfully addresses the issue described in #125 by implementing context-aware handling of enumeration references:

  1. Correct context differentiation: Properly distinguishes between XPath context (WHERE clauses) where 3-part enum references should emit just the quoted value ('Value') and expression context (CHANGE/CREATE) where string literals should resolve to qualified enum names (Module.EnumName.Value)

  2. Minimal, focused changes:

    • Added qualifiedNameToXPath() function to handle XPath-specific enum value formatting
    • Added memberExpressionToString() and lookupEnumRef() helpers for expression context resolution
    • Updated both microflow executor (cmd_microflows_helpers.go) and page visitor (visitor_page_v3.go) to use these functions
    • No unnecessary modifications to unrelated code
  3. Comprehensive test coverage:

    • New unit test file (cmd_microflows_helpers_test.go) with 5 test cases covering the core logic
    • Extended existing XPath test file (visitor_xpath_test.go) with 3 round-trip test cases
    • All tests pass as mentioned in the test plan
    • Tests cover edge cases like 2-part names preservation and string literal handling
  4. Defensive programming:

    • Proper nil checks in lookupEnumRef()
    • Graceful fallback to original behavior when enumeration lookup fails
    • Clear separation of concerns between XPath and expression handling
  5. Consistency:

    • Similar logic implemented in both microflow and page handling paths
    • Comments clearly explain the Mendix-specific behavior being implemented
    • Follows existing code patterns in the executor and visitor packages

Recommendation

Approve - The PR correctly fixes the enum value formatting issue with minimal, well-tested changes that maintain full-stack consistency. The implementation properly handles the context-dependent requirements for XPath vs expression contexts as specified in the Mendix MDL semantics. No changes are needed.


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

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Enum value syntax differs between XPath and expression contexts

1 participant