Skip to content

Add configurable view naming rules and fallback resolution to StaticViewLocator#5

Merged
wieslawsoltes merged 5 commits intowieslawsoltes:mainfrom
danwalmsley:codex/configurable-rules
Mar 11, 2026
Merged

Add configurable view naming rules and fallback resolution to StaticViewLocator#5
wieslawsoltes merged 5 commits intowieslawsoltes:mainfrom
danwalmsley:codex/configurable-rules

Conversation

@danwalmsley
Copy link
Copy Markdown
Contributor

Summary

This expands StaticViewLocator so consumers can configure naming and namespace transforms without forking the generator, and it brings the generated runtime behavior much closer to existing reflection-based view locators.

Changes

  • add configurable namespace replacement rules
  • add configurable type-name replacement rules
  • add configurable generic arity stripping
  • add configurable interface prefix stripping
  • add generic type-definition lookup support
  • add base-class fallback resolution
  • add interface fallback resolution
  • document the supported rules and fallback order in the README

Why

Many Avalonia apps use conventions beyond a fixed ViewModel -> View rename. This makes the generator usable in more real codebases while keeping view lookup static and AOT-friendly.

Validation

  • added/updated generator tests
  • verified StaticViewLocator.sln test suite passes

@wieslawsoltes
Copy link
Copy Markdown
Owner

@codex review

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review


P1 Badge Generate fallback helpers even when Build is user-defined

The fallback helper methods are currently emitted only under if (!buildMethodExists), so any locator that already defines Build(object?) will not receive TryGetFactory*/TryGetMissingView* at all. That makes the new helper-based integration pattern fail to compile for user-authored Build methods and forces consumers to duplicate fallback resolution logic manually. Keep Build conditional, but emit the helper methods unconditionally so custom Build implementations can call into generated fallback behavior.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

continue;
}

source.AppendLine($"\t\t[typeof({classNameViewModel})] = () => new {classNameView}(),");
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Avoid constructing generic views without type arguments

The mapping code can resolve a generic target view via metadata name (for example when StaticViewLocatorStripGenericArityFromViewName=false and the view type is WidgetView<T>), but the emitted factory always instantiates new {classNameView}() where classNameView has no type arguments. In that configuration the generated source becomes invalid (new WidgetView() for a generic type) and breaks compilation in consumer projects.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some fixes

@wieslawsoltes wieslawsoltes merged commit ee62606 into wieslawsoltes:main Mar 11, 2026
1 of 4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants