The 'Navigation (PostIt)' rule was buried as a sub-item under
'Conventions de code', mixed with style rules. Lift it to a
top-level section between 'Tests' and 'Conventions de code' so
contributors looking for nav guidance find it without scrolling
through editorconfig preferences.
Add a pointer to doc/architecture/postit.md for the full
topology (NavRoot, SessionStatusViewModel, lifecycle signals
vs user-driven nav). Content of the rule itself is unchanged
from 12a71ada — only the placement and the cross-link.
The two recent commits (3fbbafc4, 0065de70) replaced the
OpenSettingsRequested event + CurrentViewModel assignment with
App.PushPageAsync(vm): the VM resolves the target ViewModel
through DI, App resolves the Control through the ViewLocator,
guards against double-push, and pushes via NavRoot. The docs
were still describing the pre-refactor world.
Update three places:
- CONTRIBUTING.md — the "Navigation (PostIt)" rule now
describes App.PushPageAsync as the single channel and shows
the canonical OpenSettings command as the example.
- doc/architecture/postit.md — the Navigation section
distinguishes VM-first navigation (App.PushPageAsync) from
lifecycle signals (LoginSucceeded, LogoutCompleted) and
drops the obsolete OpenSettingsRequested row.
- src/PostIt/PostIt/App.axaml.cs — refresh the SettingsPage
singleton justification: point (c) now describes the
anti-empilement guard inside PushPageAsync, not the
OpenSettingsRequested handler that no longer exists.
No production behaviour change — doc only (and the inline
comment that referenced a removed event).
Navigation in PostIt is owned by src/PostIt/PostIt/ViewLocator.cs.
To open a screen, the caller assigns the target ViewModel to the
host's CurrentViewModel (which binds the IContentControl.Content);
the ViewLocator decides which Control instance to push and resolves
it through DI. ViewModels never instantiate views nor resolve them
from DI directly. Add the rule and a canonical example to
CONTRIBUTING.md so contributors do not re-derive the pattern from
scratch each time.
Three buttons on MainPage's toolbar are reported as inoperative
in the running app: ACL, Mes cercles, and [DEV] Signature. They
click but no dialog / page opens.
This commit adds headless UI tests that drive each button via
the Avalonia headless harness (KeyPressQwerty(Enter) on a
focused, x:Name'd button, per the CalculatorTests pattern in
Avalonia.Samples) and asserts the post-click top of
NavRoot.NavigationStack is a non-null Page.
The tests fail today on every button (stack size before == after
== 1): the click does not push anything. The bug is the user's
real complaint — the test is now wired to catch it.
To make the buttons reachable by the harness without walking
the visual tree (which does not see buttons hosted inside a
NavigationPage), name the two unnamed buttons:
- ACL -> ManageAclButton
- Mes cercles -> OpenCirclesButton
([DEV] Signature was already named OpenSignatureDevButton.)
The XAML change is cosmetic; bindings and commands are
untouched. The test pattern follows SessionStatusBannerTests:
new MainWindow().Show(), PushAsync(MainPage), drive controls via
their generated x:Name fields.
