Intégrer Bootstrap aux thèmes Dolibarr (ou autre framework css)

Développer avec Dolibarr
1

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 :slight_smile:

2

Hello
débat qui revient souvent, pour ma part je milite activement pour tailwindcss :slight_smile:

2 « J'aime »
3

La réponse de eldy sera « dolibarr est un frameswork » :slight_smile: et donc tu peux utiliser la classe fichethirdleft pour avoir un … je laisse la suite :rofl:

Bon non pour ne pas vous faire perdre de temps je colle une partie de la définition

div.fichethirdleft {
	<?php if ($conf->browser->layout != 'phone') {
		print "float: ".$left.";\n";
	} ?>
	<?php if ($conf->browser->layout != 'phone') {
		print "width: calc(50% - 14px);\n";
	} ?>
	<?php if ($conf->browser->layout == 'phone') {
		print "padding-bottom: 6px;\n";
	} ?>
}

c’est le jour où je suis tombé la dessus que j’ai zappé …

4

je ne connais pas Tailwind, mais pourquoi pas, si ce dernier permet de concevoir des thème et des modules rapidement, sans nécessité l’ajout d’un fichier supplémentaire, ni l’utilisation d’une tonne de classes dans le html. J’ai plus d’expérience avec Bootstrap que je trouve très complet et qui nécessite peu de classes dans le html.

5

Bonjour,

Le seul moyen pour arriver à faire évoluer le code de Dolibarr dans le sens que vous proposez c’est de faire un fork et de créer un nouveau projet.

6

Dans ce cas, où se trouve sa documentation?
Malheureusement, Dolibarr aura toujours du mal à évoluer en proposant sa propre tambouille css, sans aucune documentation, et d’un autre temps.

7

Désolé, je ne souhaites pas créer de projet dans mon coin, je pensais plutôt proposer de faire évoluer l’existant, être dans l’esprit communautaire quoi

8

Oui je comprends bien votre intention, mais vous n’êtes pas le premier, et c’est peine perdue.
Vous allez découvrir que les ORM c’est mal, les moteurs de templates c’est mal, et comme déjà évoqué, Dolibarr est un framework, donc tout va bien.

9

Petit florilège (loin d’être exhaustif) :

3 « J'aime »
10

Ce n’est pourtant pas un gros changement que de vérifier si un template existe dans le thème avant d’utiliser le template par défaut. Ça ne me semble pas pire que l’exécution d’un hook en terme de performance.
Et, franchement, séparer les templates des contrôleurs ne pourrait être que bénéfique pour la compréhension du code.
Il n’est même pas nécessaire de séparer en 2 fichiers, un fonctionnement dans le style «quand la fonction retourne 1, ça remplace le code «View», serait déjà un grand pas en avant.

11

Le seul gros changement, c’est de préparer les variables avant la partie «View», mais ça, ça devrait déjà être le cas…

12

@c3do nous sommes nombreux à partager ce point de vue mais … la réalité est ainsi

celà étant ça ne nous empêche pas de faire des tests, de chambouler tout ça dans le fond dolibarr est très très souple

pour ma part je ne perds plus de temps à chercher les classes css de dolibarr pour mes modules, je fais du (tailwindcss donc) et je suis passé à autre chose … un peu triste mais aussi pragmatique

1 « J'aime »
13

Je te comprends. Je préfixe également toutes mes classes css. C’est complètement absurde, tant tout ça pourrait être uniformisé

14

<mode 1er avril>
ben oui, ce n’est pas le cas ? hein des database migration ? hein des relations automatiques entre objets ? hein des transmutations ? hein des toJson ? mais tout ça dolibarr le fait mieux voyons :fleur_de_lis: et tout est super bien documenté aussi via un doxygen que le monde entier nous envie (perso c’est un ide ouvert h24 sur le code de dolibarr et des regex search dans le code pour lire la doc)
</mode>

15

Je ne pense pas que cela soit absurde. Il y a un historique de développement, et un fonctionnement inhérent au projet Dolibarr qui ne permet pas d’initier de tels changements dans le code.

Ce qui est dommage c’est que je pense que cette situation ne donne pas du tout envie aux développeurs de s’investir et à consacrer du temps bénévolement au projet Dolibarr.

16

Je vous remercie d’avoir remis en lumière ce « florilège » d’idées et de réflexions qui, bien que datant de quelques années, semble toujours trouver un écho au sein de la communauté Dolibarr. Il est vrai que, depuis lors, l’interface a bénéficié de quelques améliorations.

De mon coté, j’ai pris la décision de ne pas poursuivre le développement d’une interface considérée comme plus « moderne » dans le sens où l’on pourrait l’entendre aujourd’hui. Après plusieurs évaluations et réflexions, il est apparu clairement que la solution actuelle répond efficacement aux besoins de ma base d’utilisateurs. Par ailleurs, mes clients les plus importants manifestent une nette préférence pour des « solutions éprouvées » telles que Odoo ou ERPNext, même si, personnellement, je ne les considère pas nécessairement comme supérieures à ce que Dolibarr propose.

Il s’agit d’une concession pragmatique à la réalité du marché et aux désirs de mes clients, qui valorisent la stabilité, la fiabilité et le coté « user-friendly » par-dessus tout.

Au plaisir

17

La sensation de fiabilité passe aussi par l’apparence. Et ces 2 solutions ont clairement une interface beaucoup plus moderne.

Mais le problème n’est pas seulement une question d’apparence. C’est aussi une question de flexibilité.

Attention, je ne dis pas qu’il faut un moteur de templates. PHP fait très bien le job pour ça. Il n’y a besoin d’aucune surcouche supplémentaire inutile.

Rien que le fait de vérifier dans le thème si un template existe avant d’afficher celui par défaut serait un grand pas.

Il faudrait que je propose un exemple, parce que j’ai l’impression que dès qu’on parle de vue séparée et framework css, on imagine que ça implique énormément de changements et un moteur de template, alors que ça ne demande pas beaucoup de modifications en réalité, sauf, à remettre de l’ordre dans les contrôleurs…

1 « J'aime »