Written by Dans les deux premiers opus de cette série, nous avons discuté du public cible pour Joomla! 4 et au-delà et de la vision de l’utilisateur final. Dans ce troisième opus, nous allons voir ce qu’il en est du côté des développeurs, définir une vision pour l’architecture du code et les buts en terme de design.
Joomla! 4 et au-delà – architecture et design Dans les deux premiers opus de cette série, nous avons discuté du public cible pour Joomla! 4 et au-delà et de la vision de l’utilisateur final. Dans ce troisième opus, nous allons voir ce qu’il en est du côté des développeurs, définir une vision pour l’architecture du code et les buts en terme de design.
Cet article est une traduction de l’article Joomla! 4 and Beyond: architecture and design par Nicolas Dionysopoulos.
Accessibilité
On me dit que Joomla! a besoin d’améliorations au niveau de l’accessibilité. C’est apparemment nécessaire pour l’utilisation de Joomla! dans le secteur public pour de nombreux pays. Ce n’est pas ma spécialité donc j’imagine que cela requiert la contribution d’experts en accessibilité.
Un framework CSS moderne
Joomla! est bloqué avec Bootstrap 2 depuis longtemps. Encore pire, ce n’est pas seulement Bootstrap 2, c’est une mauvaise version de Bootstrap 2. Peut-être que cela avait du sens en 2011, mais en 2015 c’est comme essayer d’utiliser des messages de fumée alors que tout le monde sait écrire. Nous avons besoin d’un framework CSS moderne.
Il y a deux écoles pour cela. Une école qui dit que nous devrions développer notre propre framework CSS. Je ne suis pas d’accord avec cette approche car elle nécessite des talents rares que nous avons peine à trouver et cela ne garantit pas de visibilité pour le futur. Dans des mots simples, il n’est pas bon de ne pas pouvoir garantir la longévité d’un projet.
L’autre école est que Joomla! peut grandir à plusieurs. Bootstrap est un bon framework, nous devrions nous coller à lui, en nous engageant à toujours utiliser sa dernière version, au plus tard 6 mois après la date de sortie pour être en accord avec le cycle de développement de Joomla!. Nous ne devrions pas être effrayés de casser b/c en faisant les mises à jour vers la dernière version de Bootstrap. Je sais, j’étais contre cela ces 4 dernières années, mais j’ai vu que nous restions sur une version obsolète d’un framework CSS.
Jlayout pour la victoire
Jlayout est une bonne manière pour abstraire certaines complexités de l’utilisation de différents frameworks CSS. S’il vous plait, gardez en tête que cela ne concerne que le contenu statique, il n’y a pas d’interactions Javascript qui nécessiteraient de connaître A, le modèle DOM du framework et B la disponibilité du helper des fonctions Javascript. En résumé, Jlayout est un HTML abstraction layer.
Qu’en serait-il si nous pouvions utiliser Jlayout pour produire des abstractions Javascript ? Je sais que certains Jlayouts de templates chargent déjà leur propre Javascript mais cela ne concerne que les besoins natifs de Joomla!. Si en tant que développeur tiers je souhaite afficher des boutons dynamiquement, ou modifier la couleur d’un label, à travers du Javascript, la seule possibilité que j’ai actuellement est de faire des appels d’Ajax en produisant une nouvelle page HTML et remplacer le contenu de la page que l’utilisateur est en train de consulter. Cela est faux et impraticable pour plusieurs raisons !
Développons une Javascript library commune, en accord avec Bootstrap. Si un développeur décide d’utiliser le framework CSS XYZ il est obligé de produire une surcharge pour cette Javascript library commune. Cela permet aux développeurs tiers de supporter différents templates sans une vilaine approche de chargement d’une copie de Bootstrap (Yeah, j’ai fait cette merde moi-même…) ou sans devoir inventer son propre framework CSS qui n’apparaîtra pas “correctement” sur un template tiers. Supercharge de vues de template
Une des innovations de Joomla! 1.5, retour en 2006, était l’introduction des vues de template qui séparaient le code métier et le code chargé du rendu de la page. C’était génial…il y a neuf ans. Avons nous jeté un œil à nos vues de templates ? Il y a énormément de code PHP ici. Les développeurs frontend ont besoin d’avoir bien plus qu’une connaissance superficielle du PHP pour modifier le style des éléments.
En attendant, dans le monde PHP, Laravel est arrivé. Et il a ces Blade template stupidement simples à comprendre. Dans le mille ! Il est puissant et il est simple pour les développeurs frontend de comprendre et de personnaliser sans entrer trop dans le PHP. Et oui, il peut être porté à Joomla!, je l’ai déjà fait.
La syntaxe Blade nous permet de simplifier d’avantage la vie des développeurs en ajoutant des supports de construction comme @jlayout(‘com_example.foo.bar’, $this->items, $somethingElse) .Comparez ça à l’invocation du Jlayout typique dans le code du noyau et vous verrez ce qu’il en est. Avec les mots de Darth Sidious :POUVOIR ! LE POUVOIR ILLIMITE !
PHP 5.4 et plus récent
PHP 5.3 est mort depuis aout 2014. PHP 5.4 sera mort en aout 2015 mais au moins nous savons que tous les hébergements mutualisés le supportent – exceptés ceux qui ne devraient pas avoir le droit de se connecter à internet!- au moins via une option.
PHP5.4 nous permet d’écrire du code léger avec moins de duplication en utilisant les Traits. C’est la raison pratique sous la suggestion. Nous pourrions facilement raser 15% du code de nos composants natifs et réduire le nombre de bugs que nous rencontrons. 2 fois gagnant.
MySQL (et variantes compatibles) seulement
Je sais que je vais révolter les 10 personnes qui utilisent Joomla! avec un serveur SQL Microsoft et PostgreSQL. Il y a plusieurs raisons pratiques pour faire cela, comme :
Optimisation des requêtes. Nos requêtes sont suboptimales et mènent vers de mauvaises performances, en particulier sur les sites de grande taille. Si nous savons que le noyau est seulement supposé fonctionner avec MySQL nous pouvons utiliser l’expertise de MySQL DBAs dans la communauté Joomla! avec de nombreuses demandes pour rendre Joomla! rapide. C’est une des fonctionnalités majeures, et l’un des principaux points marketing.
Réduire la barrière d’entrée et d’erreur dans le déploiement. Si quelqu’un apportait une nouvelle fonctionnalité avec des modifications dans le schéma il serait supposé apporter ces changements dans le format MySQL, PostgreSQL et MS SQLServer. Dans 2 différents emplacements pour chacun d’entre eux. Cela met hors d’eux les développeurs expérimentés avec PHP et MySQL mais cela peut permettre d’apprendre et de tester contre PostgreSQL et MS SQL Server. Encore pire, les modifications des schémas PostgreSQL et MS SQL Server sont généralement fusionnées et non testées et les erreurs ne sont découvertes que longtemps après leur mise à disposition.
Nous n’avons aucun utilisateur qui supporte plus de 3 technologies de serveur de base de données. La preuve de cela est que l’intégration de PostgreSQL n’a pas fonctionné pour une longue période (au moins 1 an) et personne de s’en est aperçu. Même lorsque que nous notifions des problèmes, plusieurs mois s’écoulent avanr que les problèmes ne soient réglés. Je ne sais toujours pas si MS SQL Server fonctionne réellement.
Donc allons-y, cessons de supprimer les types de base de données aditionnels. Nous pouvons laisser les drivers dans le noyau de Joomla! (Joomla! Framework?) pour les développeurs tiers et les entreprises afin qu’ils puissent l’utiliser. Le noyau ne pourra lui fonctionner qu’avec MySQL.
Pour MySQL lui-même, puisque nous ne pouvons pas encore augmenter les pré-requis minimums vers MySQL 5.6, nous devrons mettre des tables en plein texte afin de coller à MySAM (et décapiter tout crétin qui suggère de les transformer en InnoDB). Se débarrasser de UCM
UCM est à moitié mort, et sera bientôt complètement mort, donc supprimons-le simplement. Il n’est pas indispensable pour les Tags ou le Content Versioning. Nous en avons simplement besoin entre les tables tags et content avec un champ complémentaire dénoté du type de contenu. Ensuite nous pouvons utiliser quelque chose comme une relation “morphable” comme Laravel pour les faire fonctionner. Si vous lisez la documentation Laravel vous verrez que c’est l’utilisation dans les cas de relation morphable, après tout.
Point bonus : cela réduit grandement le duplicate content et le désordre entre les tables, simplifie les requêtes et accélère les choses.
Supprimer de nombreuses extensions natives
Par le plan déjà existant. Une chose de laquelle nous n’arrivons pas à nous décoller est la mise en garde de nos utilisateurs à propos des extensions natives supportées. Je pense que la page d’accueil de l’Installation à partir du web devrait contenir deux parties : les extensions natives supportées et une liste des extensions régulièrement recherchées dans les catégories du JED. Cela nous permet d’indiquer aux utilisateurs où ils doivent aller pour ajouter rapidement des fonctionnalités qui ne sont pas présentes nativement dans Joomla!. Cette approche fonctionne parfaitement avec WordPress : la page d’accueil permettant d’ajouter des plugins est essentiellement une liste de plugins automatiques ou sponsorisés.
Espaces de nom de partout
Puisque nous utilisons une version majeure, je crois que nous pouvons définitivement casser a/b et proposer un code entièrement composé d’espaces de nom. Cela va également réduire notre code puisqu’il sera enfin possible d’étendre une classe MVC frontend à partir d’une classe MVC backend. Auparavant, cela n’était pas possible car les deux classes utilisaient le même nom. De plus, nous pouvons complètement faire disparaître Jloader. Et utiliser à la place Composer’s PSR-4 autoloader qui est déjà présent avec Joomla!. Cela nous enlèvera les bugs dans les extensions tierces causés par les classes natives qui se déplacent de libraries/joomla vers libraries/cms, ou les classes qui ne suivent pas le schéma de l’actuel autolader.
Layer de rétrocompatibilité, au moins pour 4.x
Une nouvelle vision du CMS sans les extensions tierces est inutile. C’est notre métier en tant que développeur de faciliter la transition du code écrit pour Joomla! vers Joomla! 3. Cela peut être fait en produisant une compatibilité de layer qui ajoute des classes d’alias et des backports pour le code obsolète le plus utilisé dans les APIs natives. Cela va permettre aux développeurs de travailler à leur manière vers la compatibilité vers Joomla! 4 sans avoir la sensation qu’ils doivent tout reprendre à zéro.
Cela sera très positif si nous documentons également le procédé de conversion pour le code existant. Si un des lecteurs se plaint de la faisabilité de ce plan, j’ai la page qui prouve que je documente ce que je dis. Meilleure intégration du Composer
Déplaçons composer.json et composer.lock dans le dossier libraries, pas libraries/vendor. Cela permettra l’ajout de pré-requis sans avoir à hacker le noyau.
Permettons aux développeurs tiers d’ajouter des pré-requis au Composer d’installation de Joomla! lors de l’installation ou des mises à jour des extensions. Nous devons voir si cela est possible sur les hébergements mutualisés sans accès CLI – pour le contexte, voir la discussion sur Drupal 8. Cela doit être lié à un ensemble global de com_installer. L’étude de faisabilité devra se concentrer sur la possibilité de dépendance de la fonctionnalité découvrir et sur les dépendances individuelles des étapes séparées de téléchargement et d’installation qui peuvent chacune être complétée dans un seul chargement de page.
Pour finir, supprimons toutes les librairies natives “inventée ici” en faveur de la dépendance du Composer (en particulier pour Jimage, Jgithube, etc).
DI Container
Ah, ma bête noire préférée. Actuellement, nous avons cette boite noire globale et magique nommée Jfactory. Débarassons nous de Jfactory, remplaçons-le avec un DI container (quelque chose comme Pimple?) qui est ensuite amené à l’objet d’application. Tout ce que vous voulez peut être récupéré d’une manière similaire à JoomlaApplication::getInstance()->getContainer()->user.
Je suggère également d’aller une étape plus loin. Chaque type d’extension a son propre type de container qui donne accès au principal DI container et charge les dépendances qui ont du sens pour le type spécifique du composant. Vous devriez être capable de récupérer le container d’une extension à partir de n’importe où, p.ex. JoomlaContainerComponent::getInstance(‘com_something’). Cela permet sans peine HMV. A été fait – dans FOF 3.
Révision de MVC
Je sais que le framework de Joomla! a un “nouveau MVC” que j’appelle “no MVC” parce que c’est ce dont il a l’air. Je ne suis pas d’accord avec cette approche pour les logiciels distribués en masse comme Joomla! et ses extensions. Je comprends pourquoi vous pouvez avoir besoin de cela pour les applications décentralisées. Je suggère de le garder dans le noyau pour ce type d’utilisation, au cas où, mais pas de l’utiliser comme un paradigme de développement pour Joomla!. Vous vous souvenez ce qu’est notre public cible ? Exactement.
A la place, je propose de suivre la conduite Laravel, sans les façades – une des raisons majeures pour laquelle certains développeurs sérieux détestent Laravel. Restons loin de la séparation Model vs Table. Créons un Model pour les éléments non-data-aware et un DataModel pour les éléments data-aware, en utilisant un vocabulaire et des fonctionnalités réglés similairement au Model Laravel + Eloquent est une bonne idée. J’ai déjà réalisé le travail dans FOF 3 et bloqué mon développement. Les bénéfices immédiats sont moins de code, exécution plus rapide, moins de bug et plus de simplicité pour les fixer.
Egalement, comme je l’ai dit au-dessus, ajoutons le langage de template Blade pour supporter nos Vues. Je suis à moité tenté de proposer des vues permettant d’être définies avec des formulaires XML – qui se prêtent à des fonctionnalités de RAD tels que des échafaudages – mais à moins que vous souhaitiez faire de RAD un framework du noyau, cela est déconseillé.
Bien, OK, que se passe-t-il. Mettons simplement FOF 3 dans le noyau. Je sais déjà que le plus gros désavantage sera pour moi. Cela sera cependant bénéfique pour n’importe qui d’autre d’avoir le framework RAD dans le noyau. Actuellement nous trainons les développeurs vers Laravel, ZF, etc car c’est plus simple de développer, même si vous devez tout développer à partir de zéro. Si nous supprimons l’idée que coder pour Joomla! craint” nous pouvons regagner une audience importante. Cette audience va directement ou indirectement commander le choix de plateforme pour les sites de taille importante – les nouveaux sites – et donc augmenter nos parts de marché.
API JSON avec presque aucun code
Si nous pouvions accéder aux données du CMS (et à la gestion de ces données) à travers une API JSON nous souhaiterions laisser les utilisations avancées au CMS. Par exemple en utilisant Angular.js pour le rendu des pages, la gestion à distance du contenu, les interconnexions de système, les développements d’applications mobile simples, etc.
Les bases de travail pour les vues simples de JSON avec HAL sont déjà prêtes dans FOF. Il n’y a aucune importance que le support de HAL devienne une partie du noyau ou non, nous devons l’utiliser. Je sais, nous avons déjà com_ajax, mais ce n’est utile que pour AJAX, comme en 2008 encore une fois. HAL permet aux utilisateurs d’API de découvrir le contenu plus rapidement, sans avoir à connaitre l’exact fonctionnement du serveur.
Améliorer le schéma d’installation et de mise à jour
Actuellement, chaque modification dans la base de données du noyau nécessite l’édition de 2 fichiers, un pour mettre à jour le composant com_admin et un pour l’installation, dans l’application d’installation. Cela cause des erreurs. C’est un problème qui est déjà résolu avec l’utilisation de fichiers XML, dans FOF30DatabaseInstaller de FOF, qui permettent au code de l’installeur de créer et/ou mettre à jour le schéma automatiquement. Cella simplifierait également la fonctionnalité “Corriger la base de données” : il est possible d’utiliser le même code que le schéma installeur.
Nous en avons déjà discuté pour l’intégrer dans Joomla! 3. Je pense que nous sommes prêts ? Améliorer l’installeur d’extensions
L’an passé, j’ai écrit un billet à ce sujet. Nous pouvons et nous devons ajouter les supports pour les packs de langues. Certaines spécifications ont déjà été réalisées par David Jardin. Je suis sûr qu’il y a une version révisée quelque part, mais je n’arrive pas à la trouver.
Je sais, vous pensez que je bacle cet important sujet avec 30 mots. Les deux documents en lien sont 2 fois plus long que ce billet dans son intégralité 🙂
Découpler menus et routage
Le système de menu actuel défini par le routage mène au dupplicate content et il n’est pas possible de solutionner le problème. Si un élément (p. ex. un article) peut être routé à travers 2 ou plus menus, il n’y a aucun moyen de savoir certainement quelle URL vous devriez suivre à moins que vous ne sachiez quel ID vous devez également utiliser. Si aucun ID n’est fourni, il est probable que le « mauvais » sera utilisé, menant au fait que les « mauvais » modules seront chargés.
Corriger cela PEUT causer des problèmes avec notre système de menu. Si chaque élément a une URL canonique, vous pouvez encore vous retrouver avec les « mauvais » modules chargés dans certaines situations. Par exemple si j’ai un élément menu pour une catégorie dans son intégralité et un autre élément de menu pour un de ses articles (avec différentes assignations de modules), cliquer sur cet article chargera une mise en page entièrement différente de celle chargée pour les autres articles. Ce n’est pas nécessairement mauvais, mais cela change les attentes des utilisateurs en comparaison avec Joomla! 3 et les précédentes versions.
Pour finir, com_redirect devient inportant depuis qu’il est facile d’ajouter des URLs personnalisées. Dans Joomla! 3 et les précédentes versions, la méthode typique était de créer des éléments cachés (pas de module pour les afficher) à la place.
J’ai besoin de retours de la part de personnes ayant une meilleure expérience du routage.
Test et QA
Mise à jour des règles PHPCS vers le format PHPCS 2. Cela permettra aux contributeurs de corriger eux-mêmes leur code (le fléau de notre existence pour les grandes contributions).
Les tests unitaires et fonctionnels devraient être écrits pour nos premiers cas d’utilisation communs. L’objectif à court terme n’est pas de couvrir 80% des tests, c’est de s’assurer de ne pas régresser.
Joomla! Framework
Je pense que nous pouvons maintenant tous admettre qu’essayer de créer un framework PHP générique pour concurrencer avec Symfony, Zend Framework, etc, était un gaspillage de ressources précieuses. Donc que devrions nous faire avec le Joomla! Framework ?
Une idée est de complètement l’intégrer au noyau du CMS, un peu comme l’était Joomla! Platform avant que nous l’appelions Joomla! Platform. Je pense que c’est une mauvaise approche car cela lie le développement du CMS avec le développement du framework. Ce n’est pas toujours une bonne idée. Le framework est en fait un lab R&D. Il ne faut pas mettre un lab R&D en production.
Une meilleure approche serait un projet semi-détaché. Le but de JF est de proposer une plateform stable pour Joomla! (le CMS) pour le construire dessus. Cela nécessite un changement majeur pour le développement de JF puisqu’il doit répondre à la complexité de la masse du code réparti. Par exemple, le package Uri ne peut simplement pas ignorer les besoins pour un $live_site forcé à la place de consulter globalement $_SERVER. Mais le séparer du CMS permet à la fois de faire du R&D à un certain rythme sans affecter le développement du CMS et permet à ceux qui le souhaitent de l’utiliser en dehors du CMS.
De la même manière que pour Joomla !, il est possible de récupérer les paquets JF à travers Composeur. Cela devrait être la seule manière possible, et non pas la situation actuelle qui consiste à copier à la main les fichiers .php sur un répertoire Git vers le dossier libraries/joomla.
J’aimerais discuter de ces idées dans le futur avec Adrew et Michael. Peut être que nous pourrions écrire un post commun sur l’avenir du Framework. Je pense que si nous encadrons correctement le framework (jeu de mots) cela pourrait être un jeu d’enfant pour l’organisation de Joomla!. En fait, nous devons (re)définir le public cible et discuter comment nous pouvons enfin aller de l’avant.
A suivre : l’organisation de Joomla! et le voyage à venir Crédits photo
Image by Free-Photos from Pixabay