> J'ai vu plusieurs PR, messages, etc, parlant de fonctions à remplacer > dans Clearbricks par leurs pendant en PHP natif, je souhaiterais lancer > un grande (ou pas) discussion qui je le pense va être mouvementée, mais > c'est le but.
Étant l'initiateur de ces propos, je vais préciser le fond de ma pensée. > 1) Quelle est politique à propos de Clearbricks, a-t-on les pleins > pouvoir sur la branche default, car bien que essentiellement utilisée et > hébergée (tout comme) par Dotclear, elle n'en fait pas vraiment partie > et d'autres personnes l'utilisent. De mon point de vue : oui on a les pleins pouvoirs, mais non on ne peut pas tout casser sans le communiquer (cf les utilisateurs de CB sans DC) > 2) L'avantage de Clearbricks est qu'elle fonctionne sur quasi tous les > serveurs, c'était d'ailleurs son but premier. Le temps de retard qu'elle > a par rapport aux innovations PHP n'est-elle pas un avantage ? (hormis > les deprecated comme modifier PCRE \e, mysql vs mysqli, etc) "but premier", je n'en suis pas si sûr. CB est pour moi une légère couche d'abstraction, qui pallie les quelques lacunes de PHP en termes d'harmonisation du langage. Clearbricks, c'est : 1. Quelques classes regroupant des méthodes à la sauce objet (dans common/) et quelques raccourcis (forms par exemple) 2. Une couche d'abstraction de base de données / de gestion de schéma de base de données 3. quelques boites à outils (html.filter, html validator) 4. un moteur de templates (dont on connait les limites) 5. 2-3 palliatifs à des manques php (mail, allow_fopen, zip) 6. la classe wiki2xhtml > 3) Des messages sont également passés disant "la suite c'est de s'en > séparer", bon OK je sais que, hum, non. z'en pensez ? S'en séparer complètement, peut-être pas. Se séparer de dépendances avec certains morceaux de clearbricks, certainement. Je pense notamment : au moteur de templates (à remplacer par twig), et à la couche d'abstraction de bases de données (à remplacer par PDO, qui n'était pas mature à la sortie de dotclear2). Le problème de clearbricks, c'est qu'il est confidentiel, trop peu utilisé (en dehors de dc), et pas documenté. Le maintenir en l'état (vs le fondre directement dans le code de dotclear et n'avoir qu'un seul projet), c'est fournir beaucoup d'efforts pour au final une très faible audience. On fait quoi le jour où on a cassé la compatibilité de clearbricks en le faisant évoluer pour un besoin dotclear, et où dascritch s'en plaint ? Il aurait raison de se plaindre, car il y a zéro communication sur les évolutions de clearbricks (et pour cause, ça fait des lustres que http://clearbricks.org/ n'a pas bougé d'un iota) On fait quoi, le jour où on a tout passé sur Twig, et où quelqu'un nous demande une évolution sur le moteur de templates de clearbricks qu'on n'utilisera plus dans dotclear ? Mon point de vue : * soit on dissout le code source de clearbricks dans dotclear, et on laisse le dépôt clearbricks en l'état sans évolution (de toutes façons, on n'a jamais reçu de proposition de patch pour un besoin hors DC, il n'y a pas de raisons qu'il y en ait d'autres dans la décennie à venir), et on peut tout casser dedans (surtout supprimer ce dont on ne se sert plus) * soit on fait de clearbricks un **vrai** projet, avec une documentation digne de ce nom, un bugtracker dédié, et potentiellement plus de clients hors dotclear... -- Bruno -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
