S’il y a bien un avantage de réviser tout le code de Clearbricks c’est que je commence à en connaître petit à petit tous les recoins — et ai même trouvé au passage un bug ou deux, pas très gênants, mais bien présents — ce qui me permet d’envisager une « suite » de façon plus sereine.
La suite en question ? Ça peut aller vers l’intégration directe dans Dotclear, mais aussi aller vers le remplacement de certaines parties par … et là j’hésite un peu parce qu’un des gros avantages de Clearbricks (et Dotclear) est qu’on s’appuie très peu sur du code extérieur et je trouve ça plutôt rassurant pour le futur.
Donc je reprends …
… mais aussi aller vers le remplacement de certaines parties du code par l’utilisation de librairies tierces ou par du code tout neuf, si c’est envisageable1. Sur ce point je doute tout de même un peu d’avoir le temps et peut-être les compétences pour ce faire, on verra.
Par contre il est toujours hors de question, à mon humble avis, de s’appuyer sur des gros frameworks PHP, comme Laravel ou Symfony, genre d’enclumes pour écraser une mouche pour illustrer l’usage qu’en ferait Dotclear pour publier des blogs, ce qui reste assez basique.
Pour en revenir à Clearbricks, je constate que les tests unitaires restent très pratiques pour valider mes modifications et je suis à la limite d’en écrire de nouveaux pour couvrir un peu mieux le code restant ; sauf que pas trop d’envies ni de temps pour ça :-)
Sinon, sur ma liste de possible, j’ai pour Clearbricks :
- Mettre en place des espaces de nom dans Clearbricks ; ça va casser plein de truc du côté du code tiers (plugins et thèmes, quoi que moins pour ces derniers)
- Aller un peu plus vers PSR-12 avec l’usage d’une classe par fichier, des noms de classe corrigés, … ; ça va possiblement casser aussi des choses dans l’éco-système tiers
- Ajouter la gestion du JSON dans le serveur Rest, pour l’instant assuré par du code (et un paramètre) spécifique dans Dotclear
Bref, j’ai largement de quoi m’amuser pour les semaines et les mois à venir \o/
-
D’ailleurs dans Dotclear, j’ai quasiment fait sauter tout le code Javascript « étranger », hormis jQuery et CKEditor évidemment, depuis quelques temps. Il en reste encore, mais peu. ↩︎
1 De Bernard -
Pour les je suis d’accord… Clearbricks me semble bien organisé (en rassemblant des librairies “même sujet” dans des dossiers) et avec un code sufisamment clair (et court) “lisible sans trop d’efforts” pour qui s’intéresse un peu au PHP.
Bref, une offre contraire à une “usine à gaz”, bienvenue surtout en cette période où on nous appelle à la sobriété ;-)
2 De Nicolas -
Je ne suis pas du même avis que toi mais tu le sais. Clearbricks a eu le mérite d’exister à un moment où il n’y avait pas d’alternative, à un moment où faire du code qui fonctionne dans des environnements hétérogènes étaient compliqués.
Ça n’est plus le cas aujourd’hui. Je ne connais pas bien laravel mais pour ce qui est de Symfony, on peut utiliser que les composants que l’on veut, sans ramener tout le framework.
Cela avait du sens à la création mais désormais cela ressemble de plus en plus au syndrome NIH
3 De Franck -
Je ne connaissais pas ce syndrome Nicolas :-)
Cela dit je ne pense pas en être atteint, ce n’est franchement pas la question, sinon on aurait jamais utilisé jQuery ou Codemirror, par exemple.
Concernant Symfony — que je ne connais très mal, je risque de dire des conneries — je me demande dans quelle mesure ça ne complique pas à la fois le développement (et encore puisqu’on utilise déjà Composer pour diverses choses, PHPStan par exemple) et le déploiement, ce qui serait plus pénible pour l’utilisateur final sur son serveur.
Par ailleurs, en lisant la doc Symfony je découvre que :
Or PHP 8.1 n’est pas encore un pré-requis pour Dotclear, on acccepte toujours PHP 7.4, ça coince :-)
4 De Bernard -
Perso, quand je parle “d’usine à gaz”, je me rappelle avoir tenté de lire et comprendre tout un ensemble de bibliothèques, les liens et leur utilisation… J’avoue que j’ai été vite lassé par ce qui sembait être, pour moi en tout cas, une espèce de nouveau “language” à assimiler (y compris leur syntaxe!)…
Clearbricks me semble plus simple à appréhender. Simple, et amha, plus léger.
Maintenant, c’est vrai qu’il doit aujourd’hui exister pour ces frameworks une communauté d’utilisateurs et concepteurs plus importante que celle qui concerne Clearbricks; et c’est un point important pour la maj et l’entretien des scripts au regard de la complexité de PHP aujourd’hui.
Mébon, peut-être est-ce par paresse, je préfère encore lire ce dinosaure Clearbricks que j’ai, au moins dans son ensemble, apprivoisé.
Mébon (bis), rien n’interdit de penser à un Dotclear qui reposerait sur Symfony, mais ce serait, à mon sens, pour une version 3… Qui s’y lance ?
5 De Jean-Christian Paul Denis -
Sans parler d’éléphant et de mouche, bien que ça me tente grave, un des piliers de Dotclear est son indépendance. Par pitié, ne changez rien 😅
Autoriser l’utilisation de ses
trucslibrairies en vogue autour de Dotclear par des points d’entrée ou une structure adapté (je pense ici aux espaces de noms), évidement que oui, mais je ne pense pas que Dotclear en ai besoin dans le core, sauf à vouloir tout refaire autrement.