Onboarding

Ce document sert de rampe d'accès au projet. Il n'essaie pas de tout expliquer : il te donne le bon ordre de lecture, les fichiers à ouvrir en premier et une première modification simple à réaliser sans te perdre.

L'idée du projet en une minute

netslim-blog est une application blog concrète construite sur netslim-core.

Les idées à retenir sont simples :

le code local est organisé par domaines fonctionnels, avec ici surtout Post et Site ;
les modules partagés (Kernel, Identity, Settings, AuditLog, Notifications, Taxonomy, Media) viennent de netslim-core ;
chaque domaine suit la même structure : Application, Domain, Infrastructure, UI ;
l'application sert de cas réel pour faire vivre le socle partagé dans un projet éditorial.

Ce qu'il faut comprendre la première heure

Si tu dois vite te repérer, concentre-toi sur ces deux flux :

la médiathèque (Media) avec son picker intégré à l'éditeur ;
la relation explicite Post ↔ Media via data-media-id et post_media ;
le tableau de bord /admin et les pages /admin/settings, /admin/audit-log, /admin/notifications, qui montrent comment le blog intègre les modules transverses du core.

Ils donnent une bonne vision de l'état actuel du projet : modularité, ports inter-domaines, UI admin et coordination frontend/backend.

Ordre de lecture conseillé

../README.md pour la vue d'ensemble et le démarrage rapide
ARCHITECTURE.md pour comprendre la structure du dépôt
public/index.php, bootstrap.php, puis vendor/netig/netslim-core/src/Kernel/Runtime/Bootstrap.php, vendor/netig/netslim-core/src/Kernel/Runtime/RuntimePaths.php, vendor/netig/netslim-core/src/Kernel/Runtime/DI/container.php, vendor/netig/netslim-core/src/Kernel/Runtime/Http/, vendor/netig/netslim-core/src/Kernel/Runtime/Routing/Routes.php
src/Site/ puis src/Post/ pour suivre les modules locaux
vendor/netig/netslim-core/src/Settings/, AuditLog/, Notifications/ et Media/ pour comprendre les briques transverses démontrées par le blog
FRONTEND.md si tu touches à Twig, SCSS ou à l'éditeur
DEVELOPMENT.md pour le workflow quotidien

Comment lire un domaine

Parcourir un domaine dans cet ordre :

UI/Http/Routes.php
UI/Http/*Controller.php
Application/
Domain/
Infrastructure/

Ce parcours part d'une route ou d'un écran réel, puis remonte vers les cas d'usage et les implémentations.

Première modification conseillée

Choisir une évolution petite mais verticale dans un domaine existant. Par exemple :

ajuster un message ou un champ dans /admin/settings ;
modifier un partial Twig partagé ;
faire une petite évolution dans Post ou Site ;
ajuster un style ou un comportement lié à la médiathèque.

Éviter comme première tâche :

un nouveau domaine complet ;
une modification transverse dans netslim-core sans avoir d'abord compris son impact ;
un changement d'architecture ;
une abstraction générique "pour préparer plus tard".

Ce qu'il faut garder en tête

un service applicatif sert de façade ; les workflows sensibles vivent dans des use cases dédiés ;
un contrôleur traduit HTTP vers l'application ;
Infrastructure/ contient les implémentations concrètes ;
le code transverse vient du package netslim-core ;
le frontend reste simple, mais les écrans riches ont leurs scripts dédiés dans assets/js/, puis copiés dans public/assets/js/ au build.

Après la première lecture

Quand tu te sens à l'aise :

passe à DEVELOPMENT.md pour le travail quotidien ;
garde ARCHITECTURE.md comme document de référence avant une évolution structurelle ;
ouvre FRONTEND.md avant de toucher à l'éditeur, à la modale de médiathèque ou aux assets.

3.9 KiB Raw Blame History