Bonsoir,
Juste un argument pour le camp des « no-framework » : des messages comme le votre, indépendamment des qualités intrinsèques du raisonnement, on en voit passer un à deux par an ici ou sur github… contre combien de « petites mains » (ce n’est pas péjoratif) qui débutent en php ou tout au moins n’appréhendent pas Symphony, les Design Patterns ou UML (ce à quoi j’ai été formé fin des années 90 mais qui ne m’a jamais servi à part à faire des jolies lignes sur mon CV) ?
Un des 'avantages de Dolibarr c’est sa simplicité d’appréhension, non seulement pour l’utilisateur, mais aussi pour le codeur, et ça n’a pas de prix pour un projet avant tout communautaire !
1 « J'aime »
Bonjour,
Je ne trouve pas forcément plus simple l’appréhension d’un code « spaghetti ». D’après mon humble expérience, l’éventuel temps gagné à injecter des lignes dans ce genre de code se perd par la suite en lisibilité, débug, limitations et autres problèmes.
Je suis également d’avis qu’un débutant est plus « gagnant » à travailler avec de véritables outils qui lui montrent de bonnes pratiques plutôt que d’en apprendre de mauvaises qu’il devra corriger plus tard.
UML n’est simplement qu’une expression « naturelle » du paradigme objet comme le pseudo-code l’est au langage source. Si vous essayez d’exprimer un code objet par le dessin, il est très fort probable que vous arriviez à quelque chose proche de cette formalisation.
Dans mon cas le code actuel me « limite » dans mon implémentation de certaines fonctionnalités tiers. Ce n’est pas une impossibilité mais cela induit une complexité inutile et je préférerais l’éviter.
Je suis bien sûr très reconnaissant à toutes « ces petites mains » comme vous dîtes. Je souhaite néenmoins à Dolibarr de progresser sur la qualité de son architecture et son code métier.
Je vais aller voir du côté d’autres solutions mais il semble qu’elles soient « moins » libres. Si c’est le cas, certains diront qu’« on ne peut pas tout avoir » : réalité ou limitation ?
1 « J'aime »
Bonjour,
Je ne pense pas que la question soit pour ou contre un framework, mais plutôt quel effort est à faire et quelle marche est à franchir pour faire évoluer dans ce sens.
Bien que non intervenant fréquemment dans le code, j’y ai mis mon nez et je constate qu’il est quand même organisé en objets tels que Facture, Propale, etc…
1 « J'aime »
Bonjour,
Depuis le temps que je code, je n’ai jamais vu un projet de réécriture d’application aboutir. J’ai vu des équipes motivées au départ, mais la réécriture c’est long, c’est lassant et c’est décourageant à terme.
N’oubliez pas que Dolibarr c’est plus de 18 ans d’écriture de code, ça ne se réécrit pas en 18 jours, ni en 18 semaines, ni en 18 mois.
Cdlt.
3 « J'aime »
Bonjour,
je pense qu’il ne faut pas vouloir tout reprendre pour le transcrire vers un nouveau projet a base de framework.
Personnellement, mes modules sont développés avec un moteur de template (blade), utilise un orm (eloquent), le validateur de laravel, un router développé avec fastroute le tout gérer avec un conteneur de service (qui charge une grande partie des classes dolibarr automatiquement).
Le reste est du standard dolibarr et reste du procédural.
Donc il est tout à fait possible de réécrire dans un premier temps les pages pour passer par un moteur de template (twig, blade), utiliser un orm, le composant request de symfony.
Et par la suite voir pour aller plus loin mais rien qu’en faisant ça le code sera déjà plus claire. et plus facile à intégrer a un framework
Bonjour,
Le code source de Dolibarr est disponible sur github. Tout le monde peux faire un fork et le modifier à sa guise.
Y’a plus qu’à !
Du nouveau du DoliMordern ???
Bonjour,
Personne n’a lancé quoique ce soit sur le sujet.
Cela fait plusieurs années et sur quasiment tous les projets open source que l’on voit apparaître des « nouveaux » qui veulent « tout récrire » mais vu l’ampleur du travail je n’ai jamais vu de telles projets aboutir.
Ce qui « marche » c’est de la modernisé par petits morceaux successifs.
A mon avis le fork est à éviter pour ne pas diviser la communauté qui est la force d’un tel projet.
Cette ré-écriture doit être acceptée, validée et suivie par les développeurs principaux et mainteneurs, elle doit être le souhait de la communauté, pas de quelques uns (dont je fais partie).
Si la communauté ne voit pas l’intérêt d’un tel projet ce n’est pas la peine de commencer quoi que ce soit qui finira probablement aux oubliettes.
Évidemment que la ré-écriture se fait petit à petit en dépréciant, au fur à mesure de l’intégration, les anciennes méthodes.
Je pense qu’il n’y aura pas d’autre choix que de moderniser Dolibar, j’ai installé et préparer 2 instances de Dolibar mais finalement les utilisateurs ont trouvé Dolibar pas « trop sexy ». Du coup j’ai installé un 2ieme CRM en parallèle. S’il n’est pas aussi riche que Dolibar, l’ergonomie est au top (base sur code Igniter). C’est bien dommage car si on pouvait combiner la puissance de Dolibar avec une ergonomie actuelle (Bootstrap, Symphony,…) on aurait une bombe …
Etant moi même dévelopeur d’un produit qui a un age avancé et beaucoup de ligne de code, je comprend que le sujet n’est pas simple (surtout pour la séparation IHM/code).
Je pense qu’il faudrait commencer à completer la partie API backend pour basculer vers une archi 3 tiers…J’ai fais le test avec en écrivant une application mobile qui appelle les API actuelles de Dolibar et ca fonctionne plutôt bien.
Perso ne n’aime pas trop l’idée du token en BDD, je préfère un jwt avec une validité limitée dans le temps
pour ce qui est de la réécriture, on pourrait déjà commencer par séparé le code HTML du code PHP
C’est pour ça que tous les projets de réécriture de dolibarr n’ont jamais été au bout car pour certains on a c est très bien comme ça
Je développe sur dolibarr depuis 2011 et toutes mes entreprises sont sur dolibarr, c est un bon outil mais si cela reste comme ça ne veillera pas bien car pour commencer est impossible à tester, il y a bien les tests sur les objets mais très peu de tests sur des actions complexes et on se retrouve souvent avec une version X.0.0 qui devrait s’appeler X.0.0.rc (j attend toujours la version X.0.1 voir .2)
ce n’est pas une critique envers les développeurs mais juste un constat du manque de possibilité de tests et donc de détecter des régressions.
On ne va pas avoir le choix que de commencer avec un fork qui devra suivre de près la version originale pour déjà montrer les bénéfices de ce changement
Donc s’il y a des motivés pour commencer moi je suis partant. On pourrait commencer par la partie tiers et la partie facture et pour chaque module on le ferait en plusieurs étapes
- Réécriture des pages pour passé par un moteur de templates (séparation php/html)
- passage des actions dans des classes (ce qui permettra de mieux tester les actions)
- Utilisation de phpmig
- Utilisation d’un router
Ce ne serait pas une réécriture pour passé a un full framework comme symfony mais plus une réécriture pour rendre le code plus lisible et plus testable.
Alors qui est partant ?
1 « J'aime »
Bonjour,
On part là sur des hypothèses bien plus réalistes que ce que j’ai vu jusqu’à maintenant.
Je découvre cet « utilitaire » introduit de manière presque incidente.
Je retrouve le même principe que sur Laravel. J’ai toujours du mal avec le terme « migration », parce que pour moi, ce terme désigne passage d’un état à un autre. Or, l’opération de migration est conçue comme l’outil de création des tables. Bref. Ce qui m’a gêné aussi, c’est le fait de considérer l’alimentation en données comme séparée de la migration, alors qu’elle peut faire partie intégrante de l’outil pour certaines données.
Si je comprends bien, l’idée serait de modifier la manière de gérer les changements de niveau, en passant d’un script SQL à l’exécution de ces programmes de migration. Mais dans l’hypothèse qui est envisagée, il faudrait gérer la coexistence de ces deux méthodes. Cela ne risquerait-il pas d’être délicat ?
Je ne vois pas les migrations seulement comme un outil de modification de BDD mais plutôt un outil de modifications séquencés dans un ordre précis sans être à nouveau exécuté.
je ne pense pas qu’on aura besoin d avoir les deux systèmes en même temps mais pour les migrations dont les modifications sont peut-être déjà présente il suffira de faire un test pour savoir si elle doit s’exécuter
J’avoue que j’ai toujours du mal à comprendre la crainte du « full » framework. Les éléments dont vous parlez (templates, actions, routes, etc) font partie des frameworks comme Symphony. Pourquoi ré-inventer la roue en réécrivant ces composants ou composer un framework maison ?
Si vraiment c’est plus acceptable pour la communauté de ne pas passer par un « full » framework, ce peut déjà être un bon début. Néanmoins je reste convaincu que le problème ne sera pas réglé mais simplement repoussé : tôt ou tard les outils maison montreront leurs limites et le besoin d’un « full » framework sera ressenti à nouveau.
Dans tous les cas, avant que ceux qui veulent partent sur du concret, je me permets d’insister sur le fait que le mainteneur du projet devrait être impliqué dans cette démarche de réécriture. A mon avis, ces opérations devront figurer dans la feuille de route du projet, être planifiées et intégrées au fur et à mesure dans les futures versions.
Est-ce quelqu’un a déjà pris contact avec le mainteneur sur cette problématique ? Un sondage/questionnaire pourrait également être envisagé pour promouvoir cette volonté de réécriture et essayer de prendre en compte les différents avis du mieux possible.
Simplement pour garder un maximum de compatibilité avec les modules externes (perso je dois en avoir une bonne quinzaine à maintenir régulièrement)
Le jour ou ce besoin se fera ressentir, on aura déjà une bonne base de travail.
Pour l’instant non, il est préférable d’attendre s’il y a des personnes motivés pour y participer et ensuite prendre contact
Je ne sais pas si certains intervenants sur ce fil se rendent comptent de quoi ils parlent.
Le « mainteneur du projet » pour reprendre une des expressions sur ce fil, cela fait plus de 18 ans qu’il fourni un travail bénévole. Et après ces années de travail offert à la communauté du libre, le message que certains font passer est « ton travail finalement il est pas génial, faudrait que tu réécrives tout ça… ». On croit rêver…
Si vous voulez qu’un travail soit fait bénévolement, c’est très simple, il suffit de se retrousser les manches et de s’y mettre.
3 « J'aime »
Le message à entendre ici est que dolibarr est développé avec presque les mêmes méthodes qu’au départ et qu’avec les qu’avec les méthodes actuelles ça pourrait accélérer les futures évolutions
Avant de se retrousser les manches pour attaquer un énorme travail de réécriture, il est préférable de voir qui est partant pour ne pas commencer un travail qui ne servira a rien car non suivi …
On parle beaucoup mais pas beaucoup d’engagement donc si vous êtes partant pour mettre en place un début de réécriture, faites-vous connaitre 
perso je pense pouvoir dégager une à deux journées par semaine
Je viens de profiter de la présentation des nouveautés de la v13 pour poser la question sur l’orm, gestionnaire de templates, … et sa réponse est plus que claire.
Dolibarr a déjà un orm, le principe de view controller est déjà géré via les commentaires qui sépare les actions des vues. Donc à part faire un fork, il n’y aura jamais réécriture de dolibarr.
@dev2a est-il possible de voir la réponse du mainteneur à votre question quelque part ?
@pascal_z je trouve que c’est une façon bien négative d’interpréter le message. En ce qui me concerne c’est un encouragement collectif à s’améliorer, au delà même de Dolibarr, c’est pour le logiciel libre.
Et comme cela a déjà été dit si c’est pour forker dans le vide autant s’en passer.
Si le mainteneur ne voit pas l’intérêt de faire évoluer les composants il faut peut être en démontrer ou redémontrer les limitations et expliciter en en quoi les composants actuels sont dépassés.
Si ce n’est toujours pas convainquant il est toujours possible de formuler ces évolutions comme une demande émanent de la communauté pour peu qu’elle soit soudée sur cette question.
Autrement il est peut être également possible de se faire accompagner par l’équipe de développement d’un framework que la communauté aimerait intégrer à Dolibarr.
De mon côté je travaille actuellement au développement de l’interopérabilité logicielle au niveau ontologique dans le logiciel libre. Je pense qu’au delà d’avoir des logiciels « bien » écrits il faut aussi qu’ils se parlent et coopèrent pour évoluer de la compétition vers la coopération, bien plus efficiente et humaine.
@lecoqlibre non il n’y a pas de traces de sa réponse, il a fait une réponse orale lors de la présentation et il a coupé la présentation avant les réponses aux questions
@eldy Pourquoi avoir supprimé les réponses aux questions de la présentation ?
Pour ce qui est du fork, on ne va pas avoir le choix mais il faut le faire toujours dans l’optique que ce soit merger un jour dans le code de base. C’est sur, ça va diviser la capacité de développement sur deux versions. Mais je pense que si le fork est bien fait, il sera merger à moyen terme.
