Bilan : vos façades helper

Vous avez construit un jeu de façades de confort dans mvc/helpers/, toutes bâties sur une base non instanciable, chacune centrée sur un concern.

État final de mvc/helpers/

mvc/helpers/ ├── __init__.py # ré-exporte Session, Cookies, Flash ├── _facade.py # base : namespace non instanciable ├── session.py # Session : le store + son cookie sécurisé ├── cookies.py # Cookies : cookies applicatifs génériques └── flash.py # Flash : messages one-shot

Quand utiliser quoi

Besoin	À utiliser
Créer / lire / écrire une session	Session.new / Session.get / Session.set
Lire l'id de session depuis le cookie	Session.current_id(request)
Poser le cookie de session (sécurisé)	Session.set_cookie(response, id)
Lire / poser un cookie applicatif	Cookies.get / Cookies.set
Message flash, sans redirection	Flash.set / Flash.get
Message flash sur POST→redirect	BaseController.redirect(..., flash="…") (Forge)

Les frontières à garder en tête

• Le noyau reste minimal et explicite.
  Vos façades ne font que regrouper des briques du core ; elles ne contiennent aucune logique propre.
  La sécurité (durcissement __Host-, validation, CSRF) vit dans le core, jamais dans la façade.
• Une façade = un concern.
  Session (store), Cookies (cookies génériques), Flash (messages).
  Pas de classe fourre-tout.
• C'est votre code.
  Ces fichiers vous appartiennent : étendez-les selon vos besoins (nouvelle méthode, nouvelle façade).
  Forge ne les impose ni ne les réécrit.
• Limite connue : un seul Set-Cookie par réponse (cf. palier Cookies).

À retenir

• L'ergonomie est la responsabilité de l'application : ces façades sont du sucre côté projet, le noyau Forge n'en porte aucune.
• Une base Facade commune évite de répéter le garde « non instanciable ».
• Déléguez toujours au core ; ne dupliquez pas sa logique.

Vous savez maintenant construire des façades de confort propres, sans alourdir le noyau.
Réappliquez le même patron pour tout autre regroupement utile à votre projet.