Dissection

À présent que mon environnement de travail est prêt, il est temps de se plonger dans le code et d'éclaicir la manière dont l'extension TODD va s'intégrer dans la plateforme MMI. Le noyau MMI est le framework interne maison utilisé et développer par Tiria pour les développements d'application web sur mesure. Ce noyau, dans sa nouvelle version V3, propose une architecture par surcharge ¹ et un système d'extension pensé pour ajouter des fonctionnalités sans toucher aux fichiers fondamentaux. C'est aussi un modèle plus facile à monétiser.

Fonctionnement du système d'extensions

Voici concrètement comment le plugin TODD se raccorde au reste du projet existant.

Structure et intégration

Le plugin réside dan son propre dossier, dans le répertoires spécifique pour les extensions : plugins/todd. Le cœur du système MMI détecte sa présence :

• il est déclaré dans un fichier JSON avec sa version plugins/todd/plugin.json ;
• le système gère un cycle de vie via des fichiers ad-hoc : installation (install.php), activation (activate.php) et mise à jour (update.php).

Injection dans le menu

Lorsque le système charge l'extension pour un utilisateur (connecté) de la plateforme MMI, il inclut le fichier autoload.php du plugin TODD pour chaque requête. C'est grâce à lui que l'extension s'intègre dans l'interface en deux endroits :

• ressources visuelles : préchargement de diverses icônes spécifiques au module pour qu'elles soient disponibles dans le CSS/SVG général ;
• navigation dans le menu latéral : il vérifie que l'utilisateur possède le droit ToddView et ajoute dynamiquement l'entré TODD dans le tableau de bord de la plateforme.

Cycle d'installation

Si le plugin TODD est disponible, il apparaît dans la partie Gestion des extensions. Lorsque l'utilisateur demande à installer l'extension TODD, le fichier install.php est appelé. Son appel créé les fondations du CMS des contenus TODD :

• droits et permissions — il injecte de nouveaux droits : ToddView pour la lecture et ToddEdit pour la modification dans la table native rights, rejoignant les autres droits de la plateforme pour l'utilisateur.
• nouvelles pages dans le routeur : le système natif fonctionne avec une table de routage en base de données. Le plugin y déclare ses 3 pages principales (todd, todd_content, todd_view) dans la table pages en indiquant qu'elles appartiennent au plugin_id : todd. Ainsi, si l'URL appelle ?page=todd, le noyau saura qu'il doit aller chercher le contrôleur et le template directement dans le dossier du plugin TODD.
• tables métiers : il déploie trois tables métiers dans la base de données : todd_modules, todd_contents, todd_settings.
• initialisation des sous-modules : l'extension TODD accueille elle-même des modules et joue pour ainsi dire le rôle de plateforme pour une séries de sous-extensions, dans le dossiers todd/modules/ possédant chacun son propre script d'installetion (install.php)

Exécution

Lorsque la page correspondant à TODD est appelée, le flux est est redirigé vers plugins/todd/controllers/. Le plugin possède sa propre petite architecture MVC (contrôleurs, templates, assets) mais il tire massivement parti de la classe principale App:: du noyau pour tout ce qui est rendu (templates, traduction, formatage, DB), tout en respectant l'arborescence du projet parent.

Tout en étant complétement cloisonnée et indépendante, on voit comment l'extension TODD utilise les fonctionnalités du noyau MMI ainsi que la base de donnée de la plateforme.

Architcture des modules TODD

Puisqu'une grande partie de mon travail va être d'améliorer les modules existants et d'en créer de nouveaux, il était indispensable que je me penche sur leur architecture propre.

Les modules TODD sont situés dans plugins/todd/modules/. Ils suivent une architecture modulaire dite MVC/Composant unifiée. Chaque module encapsule sa propre logique d'installation, de configuration (admin et par-contenu) et d'affichage. Chaque module a une fonction : préparer un affichage personnalisé et dynamique. Par exemple todd_quote est un module permettant l'affichage de citations avec un paramétrage sur la source (en ligne opu liste personnalisée, fréquence de chargement, etc.).

Principaux fichiers

L'architecture sépare très clairement l'installation , l'administration globale, le paramétrage par écran, le traitement des données backend et le rendu visuel asynchrone.

Déploiement et base de données : install.php

Initialisation du module lors de l'installation globale de l'extension TODD :

• création des droits spécifiques ;
• créations des tables dédiées dans la base de données (données métiers, paramètres de configuration) ;
• insertion de données par défaut ;
• enregistration du modules dans la table parente todd_modules (une fois dans cetter table, l'extension est installée) et pourra être activée par la suite.

Configuration globale : config.php

Vue (HTML/JS) du panneau d'administration global du module :

• permer à l'utilsateur d'accéder à des réglages globaux pour le modules ;
• lien avec la table via des appels AJAX pour des récupération ou des mise à jour ;
• injecté dans une modale pour l'affichage.

Configuration par contenu : form.php

Formulaire affiché lors de la création/édition d'une instance (un contenu) de ce module :

• propose des options de personnalisaiton d'apparence et de comportement au niveau de l'utilisateur final (celui qui regardera le contenu sur un écran) ;
• les données de ce formulaire sont sérialisées et concervées sous la forme d'un JSOM dans la base de données (payload_json dans la table todd_contents).

Autre configuration par contenu : admin.php

Équivalent de form pour des modules plus ancients (et plus simples).

Contrôleur backend : handler.php

Traite les requêtes AJAX (Backend PHP) spécifiques au module :

• agit en quelques sortes comme un routeur d'actions (case/switch sur des valeurs correspondant à des actions liées au module) ;
• on peut distinguer :
  • des actions admin comme la sauvegarde de la configuration globale ;
  • des action font comme la préparation et l'envoi de données formatées.

Template d'Affichage Frontend : view.php

Structure visuelle du contenu diffusé sur les écrans :

• définit la structure HTML (DOM) et le CSS par défaut du module ;
• ontient un bloc JavaScript initial qui détecte l'ID du contenu appelé et lance le chargement dynamique des données ;
• pas de requêtes SQL directes, mais délègue le travail via AJAX vers le fichier handler.php.

Logique Frontend : script.js

Fichier optionnel contenant la logique JavaScript d'animation ou de chargement dynamique :

• initilisation du module côté client (utilisation de jQuery) ;
• les requêtes AJAX vers todd.ws.php -> handler.php : par exemple pour todd_quote, récupération de la citation du jour et mise à jour le DOM de view.phpavec les nouvelles données et styles.