Je continue à tester dolibarr à chaque sortie d’une nouvelle version, je viens de consulter le code et la conception de ses modules…
D’abord mon objectif ce n’est pas de critiquer mais d’aider à orienter ce projet dans le bon sens.
J’ai déjà suggéré la réorganisation de dolibarr, mais en regardant un peu plus le code je me rendre compte de la complexité de cette tache à l’état actuelle!! beaucoup de dépendance des modules core à des classes pas vraiment génériques; avec l’utilisation par exemple les classes du dossier htdocs/core/class/html.order…php … Du coup pour modifier un module il faut se balader dans tt les sens entre les dossiers nomdumodule, core/nomdumodule, core/class/, langs/… (sans parler du mélange FR/EN pour le même module)
La première étape majeure que je suggère, et qui pourrait aider grandement l’évolution de ce projet, c’est de travailler sur un clone de module core (commande ou invoice) à placer dans un dossier nommé par exemple htdocs/components/dol_commande/ puis commencer à le faire isoler avec des classes et lib générique (transformer l’existant)… une fois le module est fonctionnel, la réécriture de toutes les autres modules sur le model mvc serait une tache très facile…
Autre chose importante, mais plus facile, c’est de transformer la gestion des menus/sousmenus/leftmenus/horizentalmenus via des tables avec l’addition d’un acl sur les menus/components/plugins
Voici un exemple de dépendance qu’il faut éliminer afin de pouvoir faire évoluer l’application plus facilement :
fichier core/class/html.formfile.class.php
une table avec la liste des modules installés puis une requête sur les modules actifs/category ne serait pas mieux? ça évite de mettre à jour ce fichier à chaque évolution…
Cet après midi, suite au post ksar, je me suis amusé à cloner le module commande… et le voilà ce brother de commande (sans le module expedition et les commandes fournisseurs)
il suffit de décompresser le zip dans htdocs ou copier le dossier components dans htdocs et ajouter ces deux lignes de code à la fin de votre fichier htdocs/main.inc.php
Pour tester l’isolation, renommer le dossier original commande de dolibarr (htdocs/commande) et utiliser l’url suivant : http://localhost/dolibarr/components/commande/ ou bien activer le module clone dans le gestionnaire des modules.
Notes :
- J’ai ajouté le mot « BROTHER2. » dans l’affichage pour tester le sur-chargement des fichiers langs
- J’ai surchargé aussi la gestion des menus…
- Faute de temps, j’ai pas réalisé des tests approfondis mais il semble que ça marche…
- Je n’ai fait que des modifications mineures en réutilisant les classes et les fichiers de dolibar6.0.5
- ça m’a pris un peu plus de 2h30 de mon temps, l’inexistence des mécanismes de l’Override des langs et menus m’a pris beaucoup de temps pour lire le code et trouver le contournement.
- Une logique: Le nom du component c’est le nom du dossier
- j’ai testé aussi de clonner commande et ses tables, ça marche mais il m’a fallu de renommer les tables dans les scripts et beaucoup d’autres variables… (désolé de le dire, je suis très surpris par l’absence de l’esprit d’abstraction dans dolibarr!! et d’un code très peu organisé!..)
- Le code du module pourrait être diviser à 2 avec des classes génériques et qui serviront à restructurer toutes les modules sur le model MVC (Exemple : remplacer la classe Commande par une classe « Component » qui sera réutiliser pour invoice/expedition/…)
…
Il reste à re-modéliser les scripts pour se rapprocher au maximum du model MVC…
Ben bref les experts de dolibarr pourraient faire un truc beaucoup plus propre/generique car certainement ils connaissent mieux que moi les libs et fonctionnalités déjà développées.
C’était l’occasion de se souvenir de mes débuts avec php…
Petite modification de façon à nommer le module comme vous souhaiter sans faire aucune modification.
ci-joint le clone de commande nommé en orders qui normalement fonctionne aussi.
à copier le dossier orders dans components et aller à dolibarr/components/orders/
