Skip to content

v0.11.0 — the behaviour outside the business classes

Choose a tag to compare

@peopleworks peopleworks released this 10 Aug 16:44
· 126 commits to main since this release

Everything that lives outside the business classes.

Read every business object in an XAF solution and you can still be confidently wrong about the
application. This release extracts the two places that knowledge hides.

Custom property and list editors

A property rendered by one does not show the control its type implies, and the business class says
nothing about it. They also live in the platform project (*.Blazor.Server, *.Win) beside the
module, so nobody reading the business objects ever meets them.

  • Detected from [PropertyEditor], [ListEditor] and [ViewItem], and from editor base types.
  • Alias constants are resolved across the solution — the constant is declared in the module
    while the editor sits in the platform project, so reading either alone resolves nothing.
  • Client assets are recorded — the JavaScript an editor cannot work without: behaviour in
    neither C# nor XML, and the reason a control breaks when somebody renames a file.
  • Also finds built-in editors reconfigured at run time through View.CustomizeViewItemControl<T>(),
    where no custom editor class exists to find at all.
  • isDefault: true means the editor replaces the default for that type everywhere; false means
    it is merely selectable in the Model Editor. Only the first is reported as used by an entity.

Version-gated data migrations

The blocks guarded by CurrentDBVersion < new Version("1.1.0.0"). Each ran once, on somebody's
production database, and never again — which is why an agent asked "why does this column contain
that?" reasons from current code and invents a cause.

Records the version, the "existing databases only" bound, which schema phase it ran in, the
methods it calls, the code, and the comment above the block — usually the only surviving record
of why.

Kept separate from seed data throughout: seed data says what a fresh database contains, migrations
say what happened to every database that was not fresh.

xaflogic explain

One self-contained HTML page explaining the application to a person — the reader who has just
inherited a ten-year-old XAF application, or has to hand one over. A map of the domain model drawn
from association attributes scattered across the codebase, every entity and property, every action
with the code it runs, an index of every criteria expression, and no request to the network.

Also

New MCP tools xaf_editors and xaf_migrations. A fourteen-entity demo application in the
repository, so the diagrams and screenshots show a realistic application that belongs to nobody.
Explicit interface implementations no longer appear as duplicate properties.

Full detail in CHANGELOG.md.