Dolimodern

Bravo! ce topic me rappelle [url=www.dolibarr.fr/forum/t/cest-peu-pour-un-projet-open-souce-age-de-9ans/24599/1 premier message[/url] sur ce forum et mon premier discours! :silly:
J’ai zappé dolibarr ces derniers mois car j’ai constaté que l’évolution de ce projet est énormément compliqué!!!

Malheureusement Il y a encore du doute sur l’intérêt de l’utilisation du MVC…

ce projet Dolimodern est vraiment intéressant!! c’est presque la réponse exacte à [url=www.dolibarr.fr/forum/t/suggestion-a-lequipe-de-dev-concernant-les-module/26695/1 suggestions[/url] sur ce forum de réorganisation dolibarr et ses modules il y a 3ans après mes premiers tests…

Bon courage!

PS: Laravel c’est le framework du futur (il faut l’admettre!!)

Bonjour @defrance,

Est ce que ce projet est toujours d’actualité ?
Cela peut m’intéresser.

Bonjour et merci à la communauté, aux développeurs,

+1 pour l’utilisation d’un framework comme Symfony ! Est-ce toujours d’actualité ?

Pour vous expliquer mon point de vu, je viens d’arriver dans l’aventure Dolibarr pour le développement d’un module dédiés aux petits maraîchers.

J’ai suivi une formation initiale d’architecture logicielle à l’université de Rennes 1 où j’ai obtenu mon master 2 il y a quelques années.

Pendant mon cursus j’ai appris différentes techniques et méthodes de développement notamment pour structurer le code. Plus particulièrement avec la programmation orientée objet ET les patrons de conceptions (appelés design patterns en anglais).

L’objectif était clair : à travers de nombreux exemples, cas pratiques d’utilisations et d’études, nous devions comprendre l’intérêt d’utiliser de tels outils partout où cela est possible et justifié.

Je dois avouer que c’est très frustrant d’arriver dans un code qui ne les utilise pas ou peu quand on y a goûté !

Si je peu me permettre cette comparaison : même s’il est possible de bâtir une maison à mains nues c’est beaucoup plus simple et rapide avec de bons outils/machines !

Avec un Framework il y a certes une plus haute abstraction du code mais ceux qui aiment voir comment fonctionne le « moteur » peuvent suivre le développement du Framework.

Qui plus est, même sans Framework on doit sans cesse s’adapter aux évolutions des technologies utilisées (par ex. PHP, MySql, JQuery ou autre), ainsi va l’informatique. Et puis il me semble qu’il est plus aisé de migrer d’un Framework vers un autre car le code est déjà bien structuré. En plus ces Framework offrent également parfois des outils d’aide à la migration.

Bref, je suis convaincu des bénéfices qu’offre un Framework bien conçu, peu importe lequel pourvu qu’il soit libre !

En tout cas pour mon module, je n’ai pas pu résister très longtemps j’ai installé Doctrine ORM car j’en pouvais plus de ne pas trouver les méthodes dont j’avais besoin et je ne souhaitais pas écrire des requêtes SQL uniques un peu partout.
En deux trois lignes de code, j’obtiens très facilement tout ce que je veux en sachant que c’est optimisé, découplé, réutilisable et évolutif.
Je peux facilement implémenter un « behaviour » pour manipuler les données qui transitent de toutes les façons imaginables. Ou je peux aussi utiliser les extensions déjà existantes.

Je n’ai pas de liste en tête mais il me manquait aussi quelques fonctionnalités ou améliorations qui auraient leur place dans le core. J’aimerais bien participer mais pour l’instant je fais ça bénévolement et j’ai plein de trucs à faire à côté aussi, comme nous tous j’imagine (entre le jardin, l’autonomie, les travaux, la musique, bref…).
Je réfléchi à trouver du financement mais c’est beaucoup de temps aussi ! Je suis pas spécialement fan du paiement/module, je réfléchis plutôt à une cagnotte pour un cahier des charges ou modélisation UML. Vous avez déjà du y penser ? Des fois je me dis que ce serait plus simple s’il il n’y avait pas que le code qui soit libre (mais la société aussi pour que nous soyons libéré du travail financé/financier, peut être un jour !) :slight_smile:

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

  1. Réécriture des pages pour passé par un moteur de templates (séparation php/html)
  2. passage des actions dans des classes (ce qui permettra de mieux tester les actions)
  3. Utilisation de phpmig
  4. 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 :wink: perso je pense pouvoir dégager une à deux journées par semaine