Skip to content

Home

Jump to bottom
Michel edited this page Oct 18, 2024 · 15 revisions

Fonctionnement de l'application

Se référer à la page How it works du guide administrateur (accès privé, demandez-moi l'accès)

Développement

Organisation

Jusqu'à aujourd'hui les fonctionnalités et la maintenance ont été principalement réalisées le créateur de l'application, avec l'aide ponctuelle (et louable) de tiers. Ce travail est fait de manière épisodique, principalement selon la disponibilité (et la motivation) de son principal contributeur.

agilare's Commits

En général j'essaie de maintenir le code à jour selon les évolutions de ses dépendances et l'entretien de base requis; ça se concrétise avec 2-3 versions par an. Il arrive que certaines périodes me permettent de faire des mises à jour plus fréquentes et/ou des développements plus importants.

Quand une nouvelle version se profile, les tests manuels et automatiques usuels sont effectués et les changements qui ont une qualité satisfaisante sont envoyé sur le dépôt princial en ligne (GithHub) dans la branche master, avec le CHANGELOG.md à jour. Après un certain délai, qui peut durer plusieurs semaines, un moment opportun est trouvé pour déployer ce code sur l'instance actuellement active darksite.ladecadanse.ch, à l'aide de Git-ftp. D'éventuels hotfix peuvent suivre peu après.

Ce travail étant actuellement accompli par une seule personne, et de l'aide est bienvenue. Le fichier CONTRIBUTING décrit plus précisément comment faire.

Branches workflow

  • master : est passé en prod une fois vérifié et testé
  • (bientôt) develop : branche de travail, mergée dans master quand sa qualité suffisante - déploiement auto. sur staging 
%%{init: { 'logLevel': 'debug', 'theme': 'base', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'master'}} }%%

gitGraph
       commit
       commit
       branch develop
       commit
       commit
       commit
       checkout master
       commit
       commit
       merge develop
       commit
       commit id: "Normal" tag: "v3.5.6"
Loading

Versioning

  • x.x.1 : fixes, nettoyage, petites améliorations, mises à jour...
  • x.1 : idem x.x.1 + refactorings & fonctionnalités

Gestion du code

PHP

JavaScript

  • dépendances : manuelle
  • (bientôt) analyse (erreurs, qualité) : ESLint

Architecture

Répartition et utilisation des fichiers

Répartition : répertoires

.
├── admin --------- pages du backoffice (accès privé)
├── app  ---------- configuration et amorçage de l'application
├── articles ------ pages simples
├── docker
├── librairies ---- moteur du site, classes utilitaires et un peu de métier (sécurité, formulaires, base de données, dates, texte...)
├── resources 
├── tests 
├── var 
└── web ----------- annexe des pages
    ├── content --- contenu interne 
    ├── css 
    ├── interface - icônes
    ├── js
    └── uploads --- contenu externe

Les répertoires var/, docker/, resources/, tests/ contiennent les fichiers de "travail" (exploitation et développement).

Les pages du site sont directement à la racine (avec une page = un script php) et regroupées en "modules" avec dans leur nom un préfixe commun comme evenement- (agenda), user- (autentification, comptes), etc. Chacun de ces modules a en général quelques pages de consultation (publiques) et d'autres d'édition (front-office pour les membres). Quelques fichiers, débutant avec _ sont des morceaux de page réutilisés dans plusieures pages (_header.inc.php, etc)

Utilisation : construction d'une page

Une page standard débute avec bootstrap.php qui :

  • inclus les valeurs d'environnement app/.env : statut de l'app, clés d'accès aux services
  • appelle l'autoload
  • définit la configuration app/config.php : données utiles pour le métier (agenda, catégories, régions, status, pagination) et paramètres de l'infra (dates, stockage fichiers)
  • crée les objets services communs (session, logger, connexion DB, validateur...) qui sont largement utilisés.

La plupart des pages, en HTML, inclueront en plus ces morceaux de page :

  • _header.inc.php : css, etc. Des balises du <head> peuvent être personnalisées pour chaque page en affectant les variables $page_titre $page_description $extra_css;
  • _footer.inc.php : charge et setup des services JS internes et externes

Les classes de librairies/ seront chargées et instanciées selon le type de page affichée (navigation, formulaire...) et le métier (événements, lieux, utilisateurs...).

Résumé conceptuel

La décadanse est une application de forme assez classique, consistant en une base de données d'éléments de la vie culturelle d'une région, présentés avec une navigation et des outils d'administration de base

Liste d'items

Liste avec filtre et tri prédéfini, avec ou sans navigation, comme dans :

  • les pages home, agenda, lieux, organisateurs
  • l'API, les RSS
  • les menus lieux & organisateurs

en tant que contenu principal de la page ou secondaire

L'utilisateur consulte des items : events, lieux, organisateurs, users; avec lesquelles il navigue en

  • filtrant : selon le jour/la semaine (events), des mots-clés (recherche), une région, une categorie, un offset (pagination)
  • triant : les derniers, par heure
  • et peut effecuter des actions sur celles-ci (dans l'admin, outil pour remplacer plusieurs events)

Item (event, etc.)

L'utilisateur focus sur un item dans une page dédiée (ou au sein d'une liste) dans laquelle il peut naviguer (préc/suiv. dans Événement), voir des sous items : salle, description, fichier (flyers, etc.) et éventuellement faire des actions sur cet item :

  • supprimer
  • formulaire
    • ajouter (nouvel event, lieu, etc., création compte)
    • modifier
    • copier (event)
    • meta-actions (event : envoyer, signaler erreur, etc.)

2 modes utilisateurs avec des niveaux de droits

  • public : consultation
  • connecté avec plusieures possibilités (ci-dessus) selon son niveau (admin, acteur culturel) : édition

Plan de l'application avec évaluation du legacy & pistes de modernisation

Estimation de la qualité du code :

  • 🔵 : potable
  • 🟡 : médiocre
  • 🔴 : mauvaise

Pages & actions

Modules

  • events
    • liste (agenda) 🔴
    • search 🔴
    • event 🟡
      • actions 🟡
      • copy 🔴
      • edit 🔴
      • email 🟡
      • report 🔴
      • ics 🟡 -> librairie
  • lieux
    • liste 🟡
    • lieu 🔴
      • edit 🔴
      • salle-edit 🔴
      • text-edit 🔴
  • orgas b
    • liste 🟡
    • orga 🔴
      • edit 🔴
  • users
    • user 🔴
      • edit 🔴
      • login 🟡
      • register 🟡
      • reset-pwd 🔴

Inter-modules

  • home 🟡
  • api 🟡 -> API platform ?
  • rss 🟡
  • multi-suppr 🔴
  • admin 🔴 -> librairie "admin panel"

Composants

"" = pas implémenté en tant que tel, concept à implanter

Core

  • security (authentification, authorizations) 🟡 -> Symfony Security ou autre
  • "models" 🔴
  • "DTOs" 🔴
  • configurations 🔵 -> a config library

Gateway

  • "routing" 🔴 -> Slim, etc.
  • forms 🔴 -> Symfony forms, etc
  • validation (query params, forms...) 🟡 -> Symfony validation, etc.
  • navigation (menus, calendar, regions, tri, pagination) 🔴 -> APIplatform, Pagerfanta, Fullcalendar, Carbon, etc.
  • "template system" : inclusions, pages meta, styles 🔴 -> Twig ou Blade
  • "i18n" 🔴 -> Symfony Translation
  • articles 🔴 -> a micro CMS
  • dev (whoops) 🟡

Infra

  • mailing 🟡
  • dbconnector et repositories -> DBAL, etc.
  • uploads process storage 🔴 -> recycle code from ladecadanse4, look for libraries
  • dates -> php, calendar lib...
  • session -> Symfony, etc.
  • external : maps, analytics, tinymce... 🟡 -> Openstretmap, Matomo, markdown editor...
  • logging 🟡 -> Monolog

View

  • document structure (html, json...) 🟡
  • accessibility 🔴
  • scripts 🟡
  • styles (css & icons) 🔴 -> UIKit, etc.
Clone this wiki locally