ce n’est pas un module.
ce que tu fais c’est:
- installer éventuellement le menu fixe de dolimodern
- puis installez la partie laravel. vous obtiendrez une nouvelle façon de voir dolibarr.
tout ce qui était dans / htdocs se trouve maintenant dans le répertoire / Modules
toutes les requêtes passent par /index.php
il recherchera une route puis passera par un contrôleur pour obtenir une vue, le code HTML de dolibarr
ok, mon explication. Si vous regardez la version actuelle de Dolibarr, tout se trouve dans / htdocs et il y a plusieurs choses qui doivent changer:
- les pages sont générées en faisant écho à l’information (c’est une ancienne méthode de programmation, comme celle qui a été postée sur un problème de github)
- les pages sont générées en allant à /some-page.php?long-line-of-parameters. c’est une ancienne façon de gérer les routes
- les fonctions et autres codes, comme les tables de base de données, sont écrits en français
- Peut-être d’autres choses
alors regardons quelques changements:
- déplace tous les fichiers de / htdocs ailleurs et laisse toutes les requêtes passer par /index.php
- alors vous devez changer tous les appels en /some-file.php?param=some-long-parameter
- pendant que vous y êtes, transformez tous les échos en véritables modèles
- alors vous avez toujours l’ancien code, les anciennes fonctions, les tables de base de données et les champs non traduits
je l’ai regardé différemment:
- traduire des tables et des champs
- Transformez tout le code html de Dolibarr en de très jolis modèles (et appliquez les css de Dolibarr, pour conserver le look & feel vieux
- générer des modèles, des contrôleurs, des routeurs à partir de la base de données (son possible)
- Assurez-vous que tous les itinéraires fonctionnent, ils pointeront vers des comtrollers «presque vides», qui appelleront les vues html de Dolibarr.
- ils utiliseront des « modèles » qui indiqueront les relations existant entre les bases de données
Ce que vous avez maintenant, c’est:
- tous de dolibarr
- avec les vues originales dans les modèles
- avec tables et champs traduits
- avec de toutes nouvelles routes qui passent par /index.php
- avec du code qui est en dehors de / htdocs (nouvelle méthode de programmation)
Ce que vous n’avez pas (encore), c’est:
- toutes les fonctions de Dolibarr qui rendent Dolibarr magique, copié dans les contrôleurs (et modèles)
- toutes les fonctions de Dolibarr modernisées
- toutes les fonctionnalités de Dolibarr refactorisées et traduites
J’ai commencé par créer une configuration de menu fixe. C’est laradock, mais ensuite coupé et nettoyé.
Désormais, tous les développeurs travaillent avec la même configuration. pas plus ‹ ça marche sur ma machine ›
Mon idée était de faire un exemple de ce qui est possible.
Si vous souhaitez utiliser Symphony:
- renommez tous les fichiers .blade.php en fichiers de modèle Symphony.
il y a très très peu de templates de lames dans les fichiers .blade.php
- changer les modèles en modèles Symphony
- modifier les itinéraires en itinéraires Symphony
- changer les contrôleurs en Symphony
si vous pensez que Dolibarr est un framework et que vous n’avez pas besoin d’un autre framework:
- examinez de très près les fichiers de migration de ‹ modern-dolibarr ›. beaucoup de tables et de champs ont été traduits. appliquer cela à Dolibarr. il ouvrira le code source aux non-francais
si vous voulez essayer modern-dolibarr:
- installer docker-dolibarr (facultatif)
- Téléchargez modern-dolibarr et assurez-vous que le répertoire / public est la « racine du document »
- lancez composer composer, il installera laravel
- copier .env.example dans .env et remplir les informations de la base de données
- lancez php artisan migrate (après avoir créé la base de données
quand vous utilisez docker, l’hôte mysql est ‹ mysql › au lieu de ‹ 127.0.0.1 ›
- lancer npm install ou yarn install
- lancer npm exécuter dev ou yarn exécuter dev
après la migration, allez à http: // votre-nom-serveur / il affichera la page de connexion
Je travaille sur plus d’améliorations à moins qu’il n’ait aucune chance d’être
4 « J'aime »
Bonjour 
@UnderDog merci pour ces explications, n’hésite pas à détailler ici tes updates nouveautées… 
l’avantage avec les « anciennes méthodes de programmation » c’est que c’est facile à débugguer.
avec les routes, les contrôleurs et tutti quanti, c’est plus la même
enfin il me semble…
1 « J'aime »
En fait, je pense surtout que l’utilisation d’un Framework populaire genre Symfony, CakePHP ou Laravel par exemple apporte un certain cadre et une structure.
Cela permet donc de booster les contributions de développement car quelqu’un qui a déjà travaillé avec ces Frameworks a déjà des habitudes et des connaissances liées à ceux-ci et aux ORM (le mapping objet-relationnel) qui y sont adossés sans avoir à apprendre une nouvelle organisation/structure de projet.
Après, il faut prendre en compte « l’historique » du projet Dolibarr qui fait qu’à l’époque de la conception initiale du logiciel, les frameworks étaient sans doute moins populaires et répandus qu’actuellement.
Par contre, je ne suis pas d’accord avec toi quand tu dis que les « anciennes méthodes de programmation » sont plus faciles à débugguer ; j’aurai plutôt tendance à dire l’inverse 
Justement les framework à code MVC (Modèle / Vue / Contrôleur) permettent d’isoler l’application en différentes couches et il est plus simple de s’y retrouver (enfin je trouve) Ça permet au moins de séparer la partie logique/business de l’accès aux données (lorsque c’est bien fait car certains frameworks n’empêchent nullement d’accéder aux données directement depuis un contrôleur par exemple) et de l’affichage.
Après, quand on a un existant comme Dolibarr, c’est pas possible de jeter le bébé avec l’eau du bain 
Des actions de refactoring sont entreprises mais lentement car ça demande du temps pour pas tout casser et préserver un minimum la compatibilité avec les modules tiers ^^
1 « J'aime »
Alors ma vision après un mois de symfony c’est que les choses sont effectivement rangé de meilleure manière, j’ai l’impression de moins écrire de code et les messages d’erreurs sont plus simple à analyser…
J’ai conscience que développer un dolibarr avec un nouveau framework ne se fera pas d’un coup de baguette magique et ce n’est pas mon but, j’espère pouvoir reprendre le maximum de choses et pouvoir mettre en place un minimum de modules pour démontrer la viabilité de l’ensemble (Tiers, produits/service, utilisateurs, propale, commande, facture client)
Pour le moment nous serions un groupe de 3-4 au niveau de la formation à partir sur ce projet pendant un mois, je ne sais pas encore si on pourra ouvrir celui-ci avant la fin de la formation, sans doute continuer un peu durant les vacances d’aout et présenter l’ensemble à la rentrée.
1 « J'aime »
Bonjour
Laravel Symphony Cake Zend pff va falloir que je m’y mette un de ces 4 
Bonjour
Un petit Up pour vous annoncer que mon projet autour de symfony et Dolibarr avance bien, je vais me laisser les vacances (en même temps que la montée de version des mes modules pour la V10 en cours) et présenter quelques chose de stable à la rentrée
Quelques précisions :
- Le but n’est pas de réecrire totalement dolibarr mais de poser une nouvelle architecture et refondre ensuite dans un second temps et évitant les conneries présentes dans le code actuel…
- L’interface sera très proches de dolibarr mais en bootstrap (SB admin 2)
- La structure de la base de donnée va profondément évoluer (on va enfin faire du propre), j’ai pris partie de corriger pas mal de trucs qui ne me convenait pas (par exemple il sera possible d’avoir autre chose que des produits et des services). Une moulinette magique permettra de transférer une base dolibarr dernière version vers la base du nouvel outil.
- en terme de fonctionnel on gardera la logique de simplicité de dolibarr mais certaines notions seront ajouté pour simplifier certaines fonctions (le multi-entité, le multi-devise, le workflow-statut des éléments)
Bref je ne suis pas partie dans l’idée de refactorer dolibarr mais de faire du neuf en permettant de récupérer les données et ne pas trop perturber les anciens utilisateurs de dolibarr
2 « J'aime »
1 « J'aime »
On en reparle à la fin du mois…
1 « J'aime »
Bonjour,
Merci @Defrance pour ton travail sur ce sujet.
Je pense que c’est effectivement nécessaire d’en passer par une refonte total avec un outil de migration.*
Par contre, je me demande ce que notre amis @Eldy pense de tout cela ? Tu as eu l’occasion de lui en parler ?
Par ce que vu son discours actuel, j’ai un peu l’impression qu’il va rejeter cela en bloque, ce qui risque de te mener à un « fork » et à une division de la communauté, ce qui a mon avis ne serrait pas une bonne chose.
Bon courage en tout cas !
Je n’ai pas trop l’habitude de parler au nom de quelqu’un et je doute qu’Eldy ne donnera pas son avis quand il le souhaitera.
Pour ma part je ne considère pas vraiment ce projet comme un fork, car je part « from scratch », je ne garde que le fonctionnel et l’ergonomie afin d’assurer un basculement simple depuis dolibarr
même si je continuerai de développer et maintenir des modules pour dolibarr (et il sera possible sur la nouvelle plateforme d’installer des modules extensions).
Bonjour
Du nouveau ?
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! 
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 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 !) 
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 »
