Bonjour,
Je me permet de lancer un débat, au risque de me faire défoncer
Chacun d’entre nous, développeurs de modules et thèmes, avons à créer un fichier CSS pour la plupart de nos nouvelles créations, généralement par manque de classes pour nos besoins, mais aussi parfois par manque de modernité.
Au final, un client disposant d’une dizaine de modules et d’un thème personnalisé peut se retrouver avec une dizaine de fichiers CSS à charger.
Chaque thème et chaque module viennent avec leurs propres classes CSS. Ce qui augmente le risque de conflits à chaque nouveau module installé, peut rendre les intégrations fastidieuses, et rend l’apparence du site totalement inconsistant.
J’ai l’impression qu’il y a une certaine réticence à intégrer un framework CSS, plus du côté de l’asso Dolibarr que des développeurs de modules et de thème.
Pourtant, il y a plusieurs avantages à ce que le thème de Dolibarr soit basé sur un framework CSS:
- Mettre à disposition des développeurs une bibliothèque CSS complète et documentée (le manque de documentation est souvent la cause de la création de code qui allonge inutilement le chargement);
- Fini les conflits! À chaque version de Dolibarr, il est possible de mettre à jour le thème par défaut vers une version supérieure du framework. Chaque module/thème repose sur le même fichier CSS. Les développeurs de modules peuvent adapter leurs templates en une simple vérification de version de Dolibarr;
- Réduction du nombre et du poids total des fichiers CSS à charger chez le client final, et donc chargement plus rapide de Dolibarr. Je pense en effet que ne pas intégrer de bibliothèque CSS en raison du poids de celle-ci est un mauvais calcul sur un projet communautaire comme Dolibarr.
- Un développement plus rapide des modules et des thèmes, puisqu’il n’y à plus à concevoir de fichiers CSS mais uniquement à renseigner des classes dans nos templates. Avec un framework, les développeurs de modules auront rarement besoin d’ajouter du CSS supplémentaire.
- En finir avec jQuery: Ce fut une superbe bibliothèque, mais elle est désormais totalement inutile !!
- Élaborer des thèmes plus modernes. Parce qu’on ne va pas se mentir, malgré tous les efforts de l’Asso, l’apparence générale manque de modernité, ce qui peut rebuter les nouveaux utilisateurs à l’adopter;
- Uniformisation de l’apparence: L’apparence des pages du modules sera toujours identique à celle du thème installé;
Pourquoi l’intégrer aux thèmes plutôt qu’à Dolibarr même: Tout simplement pour que les développeurs de thèmes puissent optimiser le fichier final qui intègre le framework avec un style personnalisé.
Il faudra bien entendu que le développeur base son thème sur la même version du framework que le thème par défaut de Dolibarr, et que toutes les fonctionnalités du framework soient présentes pour être à disposition des autres développeurs.
Seul hic, et pas des moindres: Dolibarr n’est pas pensé pour l’utilisation d’un framework.
- Les contrôleurs ont rarement une vue à proprement parler. Même dans un fichier unique, c’est tellement le foutoir que la partie soit disant «View» est souvent entrecoupée de code censé se trouver dans la partie contrôleur.
- Dolibarr ne permet pas aux développeurs de thèmes de proposer ses propres vues. Je ne pense pas que ce soit ultra complexe à mettre en place, mais c’est nécessaire pour utiliser un framework CSS.
Le but est de lancer un débat constructif, donc soyez sympa, argumentez sans idée reçu, s’il vous plaît. Merci