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).
Two related changes that close the loop on the SettingsPage
push semantics.
1. The SettingsPage used to be registered as Transient. Each
click on the Paramètres button resolved a fresh instance,
re-bound it to the Settings singleton, and pushed it onto
the navigation stack. Repeated clicks accumulated stacked
instances, each fully bound, and the user had to tap Back
N times to leave. The fix is to register the page as a
Singleton in the DI container. There is now one and only
one SettingsPage ContentPage for the lifetime of the app:
- its DataContext is wired once, at composition time
(just after the ViewLocator is added to DataTemplates),
not on every push;
- the OpenSettingsRequested handler is a pure navigation
concern, with no DI resolution and no rebinding;
- the in-memory Settings state is preserved across visits
(any in-flight edit stays in the same instance).
2. The OpenSettingsRequested handler is guarded so that if the
SettingsPage is already at the top of NavigationStack, the
push is a no-op. NavigationPage.PushAsync does not
deduplicate; without the guard, calling it twice with the
same instance pushes it a second time, and the user has to
tap Back twice to leave. The guard is a reference comparison
on NavigationStack[Count - 1] against the singleton
instance, which is correct precisely because the page is
a singleton.
doc/architecture/postit.md is updated to match: the DI table
reflects the new lifetime, and the 'Garde anti-empilement'
section is rewritten from 'to be implemented' to the actual
implementation, including the rationale for reference
comparison and the cross-dependency between the singleton
lifetime and the guard.
The Settings-singleton invariant (in the same doc) is
unchanged: Settings is still a singleton, and adding a
transient override would still be the bug it always was.
The new SettingsPage singleton sits alongside it cleanly.
Build: 0 errors. Tests: 3/3 SettingsLoadTests green.
Two long-standing gaps in the architecture documentation are
filled in this commit:
1. doc/architecture/postit.md is new. It covers everything the
existing postit-oidc.md does not: the one-codebase /
three-frontends topology (PostIt lib + PostIt.Desktop +
PostIt.Android + PostIt.Browser), the custom ViewLocator
that resolves ViewModel -> View through the DI provider
(and why we don't use the Avalonia.Mvvm default), the
composition root in App.OnFrameworkInitializationCompleted
with the full DI registration table, the navigation flow
driven by SessionStatusViewModel events, the ViewModel
lifetime conventions (singleton vs transient), the
[RelayCommand] XAML binding conventions (referenced to
AGENTS.md for the canonical version), and the per-page
DataContext / role table. The Settings-singleton invariant
is called out as a guard rail, and the SettingsPage
anti-empilement invariant is documented as the TODO the
code still owes us.
2. doc/architecture/decoupage-organisation.md is brought up to
date. Its project table listed 7 .csproj; the repo has 14
(the four PostIt projects, the tests satellites, the cli
tool). The table is extended, the ASCII diagram picks up
the PostIt block, and an Outils et tests section lists
the test / CLI satellites that were missing.
doc/README.md is updated to index the new postit.md. No code
changes in this commit, no behaviour change.
The previous "PostIt: fix blog API double-prefix" commit changed
DefaultPathPrefix from "api/blog" to "blog" without spelling out
the convention. Future-me (or anyone else touching ApiUrl) needs
to know that BaseAddress already terminates in /api/v1/ and that
pathPrefix is relative to that.
* BlogApiClient: add a <para> in the class summary that names the
convention, points at the matching controller route, and
cross-references the fix commit.
* postit-oidc.md: add a row in the "Composants partagés" table
with the same warning, in the architectural-doc voice.
Yavsc.Web is an empty template/draft project — no useful code,
conceptually a duplicate of the front that lives in Yavsc.Org.
Remove its mentions from:
- Dockerfile, Dockerfile.backend: the COPY src/Yavsc.Web/*.csproj
step is useless (the project is referenced nowhere downstream)
- ROADMAP.md: the 'Perimetre technique' table no longer lists it
- doc/architecture/decoupage-organisation.md: removed from the
ASCII diagram and the per-project table
Note: this commit only removes references; the empty project
itself (src/Yavsc.Web/) and the yavsc.sln Project() entry are
left in place for now. A future commit can rm -rf the directory
and prune the .sln when we're sure nothing else still depends
on it.
When documenting the per-project layout in the previous commit,
I described Yavsc.Blogs as 'Sous-domaine front web specifique
au blog', which is wrong: Yavsc.Blogs contains only ApiController
classes, services and models — no Razor views. The plan is to
deploy it as a headless backend API on a dedicated subdomain in
production, while the blog front (Razor views) stays in
Yavsc.Org to share rendering and auth.
Correct the description, the ASCII diagram, the table row, and
the 'why' paragraph accordingly.
Documents the per-project layout under src/ (Abstract, Server,
Org, Api, Blogs, Web, Org.Tests) as one of the two remaining
items of Jalon 0 in ROADMAP.md:
'Decoupage Yavsc.Org vs Yavsc.Server vs Yavsc.Api clarifie
dans l'Architecture'
The page is referenced from the new doc/README.md index, and
will also be linked from CONTRIBUTING.md in the next commit.
doc/Architecture.md was 436 lines and growing; this commit
extracts each non-trivial subject into its own page under
doc/architecture/ and reduces the root document to a table of
contents + transversal sections (vision, stack, admin rights).
New pages (under doc/architecture/):
- workflow-multi-parties.md : client / fournisseur /
coordinateur roles, sous-traitance, project states, B2B/B2C,
domaine musical production flow.
- domaine-musical.md : titres collaboratifs (formats, flux de
production, contraintes de licence).
- licences.md : LicenceModele, CC/ODbL seed, badge projet,
cycle de vie.
- domaines-activite.md : arbre des activites, Droit a la
racine, DomaineActivite model.
- dictionnaires-metier.md : regle d'heritage, DictionnaireMetier
+ TermeMetier, cycle de vie d'un terme. Absorbs the previous
doc/Dictionnaire.md draft.
- offres-frontmatter.md : ClasseFormulaire / ClasseDevis,
OffreFournisseur, Demande, parsing YamlDotNet (introduit dans
4034c399 Front matters). Absorbs the previous
doc/Formulaires-devis.md and doc/Demande.md fragments.
- postit-oidc.md : documentation du client desktop PostIt,
custom URI scheme (RFC 8252 §7.1), composants partages,
plateformes, UX observable, persistance et reprise au boot,
garanties testees.
Architecture.md (436 -> 66 lines) keeps the vision, the stack
overview, the admin rights section, and a TOC table pointing at
each detail page. The "A documenter ensuite" backlog is kept
at the end.
Cross-links are relative: from Architecture.md the links go
architecture/<page>.md; from inside doc/architecture/ they go
../Architecture.md or <sibling>.md.
