@eldy j’aurais bien voulu ton avis / aval / au moins valider le fait que l’information est claire, partagée et transparente 
Actuellement, on a un fichier API par module. Beaucoup de module n’ont qu’une classe métier, du coup, cela donne l’impression d’un fichier API par object, mais certains modules, par exemple les factures ont des objects facture et des objects paiements. Et c’est bien dans la même API. Un module = 1 API.
Le module builder me semble bien en phase. Par contre, je ne suis pas sur que le dev soit terminé pour gérer n objects mais il a été pensé pour avec des route qui devrait être /mymodule/myobject1/{id} pour l’objet 1 et /mymodule/myobjectn/{id} pour l’objet n.
Par contre attention, le dev de support des API dans ModuleBuilder n’est pas encore terminé car ceci ne fonctionne pas encore mais on est tout proche…
Toutefois, rien n’empêche un éditeur de module de créer un fichier par object.
Pour ce qui est du MVC, on est sur des API, le V (la Vue) est donc limité (à du formatage json). Le M, le modèle, est matérialisé par les classes CRUD métiers existantes de Dolibarr, et le contrôleur C, matérialisé par le fichier api_mymodule.class.php qui offre le point d’entrée qui pilote les classes CRUD.
Dolibarr s’appuie sur le Design Pattern « Table Module » pour ce qui est du Code Organization (définit par Martin Fowler) et du Design Pattern « Active Record » pour ce qui est de l’accès aux données (Voir Language and development rules - Dolibarr ERP CRM Wiki)
L’archi actuel des API respectent bien tous ces patterns.
+1 pour implémenter les espaces de nom PSR-4 dans le module buider.
Personnellement, je n’utilise pas module buider, mais j’utilise déjà les espaces de nom, et ça me prend moins de 10 lignes de code dans la class actions_mymodule
Ça permet de connaitre le chemin vers les fichiers de classes à coup sûr.
Ensuite, j’implémente un hook sur chaque page et ça se fait tout seul.
Je ne sais pas si c’est la meilleure façon, mais c’est celle qui me convient actuellement.
Cela dépend. Evoluer vers quoi, comment ?
Chaque question, commentaire de l’un ou de l’autre étant indépendante et pouvant faire l’objet de réponses ou retour différents, j’avoue ne pas être capable de donner de point de vue plus claire sur un flux complet d’informations ou de questions.
Le lieu pour proposer des évolutions de code (si c’est de cela qu’on parle), reste toujours via des PR github (c’est beaucoup plus claire et plus facile d’échanger sur des évolutions de code par ce canal que via forums).
Certains intégrateurs font des PR de type « draft » pour permettre de proposer des évols de code de manière publique sans risque d’intégration par erreur. C’est une bonne pratique. Le public touché est aussi plus adapté en ciblant les développeurs même via des PR, le forum étant plus généraliste). Cela permet aussi de valider qu’une proposition est en phase avec les critères qualités de la CTI.
1 PR par type de proposition d’évol est recommandée afin d’avoir des échanges adaptés à chaque proposition sans le bruit géneré par les echanges sur d’autres. L’usage de l’anglais doit aussi être de mise pour l’aspect suggestion d’évolution de code dans la description d’une PR.
Hé Laurent,
il ne faut pas non plus faire l’aveugle … j’ai clairement isolé TROIS points dans mon message initial :
et non, je ne vais pas aller tenter d’expliquer en anglais sur github ce genre de choses, j’initie un débat sur un espace public communautaire dans ma langue maternelle qui me permet de ne pas faire de contresens, si ça provoque un peu de réponses permettant d’affiner les points ça se transformera sans doute en PR mais c’est trop tôt pour ça. (exemple le coup des POINTS pour la géo-localisation, j’en ai parlé sur le forum avant ce qui permet d’avoir un espace où plus tard on peut se référer si on a besoin de « revenir » sur le sujet alors qu’une PR se ferme et ne sert plus à rien).
C’est vraiment une manière d’aborder les questions, je n’ai pas le point de vue du développeur qui force les gens à venir sur mon outil de développeur (git). Je m’adresse à des développeurs certes mais je veux faciliter la possibilité de suivre les débats pour des non développeurs qui sont directement impactés par nos travaux…
Donc à reprendre les questions:
- espace de nom pour les modules dolibarr → oui ou non ?
- PSR-4 pour les modules → oui ou non ?
- un objet class MyObj (fichier MyObj.php) → un controleur class MyObjController (fichier MyObjController.php) → oui ou non ?
1 « J'aime »
Je ne pense pas qu’un sujet de PSR-4 parle à un non développeur, ni la notion « d’espace de nom » ou encore moins les questions de design pattern. Pour moi, un « non développeur » c’est une personne sans connaissance de terminologie propres au développement informatique. Mais c’est un point de vue purement personnel.
En tout cas, pour les 3 sujets différents cité, comme cela se matérialiserait par du changement de code , cela relève pour moi de notion pure développeur, donc
à aborder sur l’espace officiellement dédiés au suggestions d’évolutions de code, donc à des PR github, en anglais, pour que le maximum de développeur puissent en avoir connaissance et participer.
Le forum est certe très actif pour de l’aide, mais fréquenté que par une minorité de développeurs qui contribuent au code.
Juste une remarque nous sommes dans la rubrique « développer avec dolibarr » du forum…
Donc oui ça s’adresse aux développeurs et ça permet à des non développeurs de suivre et pourquoi pas de lire, essayer de comprendre, suivre des liens, apprendre des choses et surtout « voir » qu’il y a des échanges qui mènent à des décisions et des solutions …
Je le concède sur le titre de la catégorie. Toutefois en tant qu’utilisateur du forum, j’ai l’impression que cette catégorie a était pensé pour permettre de demander de l’aide à des développeurs et non à orienter le core. Les admin du forum pourront dire l’idée qu’il y avait derrière en créant cette catégorie.
J’essaie donc d’y participer car elle existe, mais en y apportant la réponse qui me semble la plus pertinente.
Et ici, mon point de vue est que, une question d’évol du code ou d’archi sont des questions qui méritent de toucher le maximum de contributeurs développeurs, et donc d’être placé sur l’espace centralisé dédié à cela, à savoir le suggestion via Issue ou PR github (la plupart des contributeurs actuels utilisant ce canal la, je pense qu’il est préférable de continuer sur celui la et de ne pas dupliquer chaque outil). Maintenant, rien n’empêche à qui le veut d’échanger sur ce forum aussi, chacun est libre de le faire ou pas, mais à titre personnel, je préfère me concentrer, pour les questions d’évol du core, uniquement sur le canal qui est utilisé par la majorité des contributeurs.
Bonjour,
« Développer avec Dolibar » a effectivement été créé pour les développeurs de modules puissent échanger.
Mais comme je l’ai souvent répété, je trouve qu’il manque des « liens » entre la communauté développeur et la communauté « utilisateurs ». Le forum pourrait être une solution (mais je te l’accorde, plutôt le forum anglais pour que tous les développeurs puissent échanger).
2 « J'aime »
@eldy je viens de voir qu’il y a exactement un truc sur github sur un des sujets abordés par mon message sur le forum
comme nous pouvons le constater il y a une forte interaction sur github avec les autres développeurs, bien plus que sur le forum francophone 
je ne vois pas pourquoi un message que j’irais y poster y trouverait plus de visibilité et d’interactions que celui que j’ai mis en lien … mais bon je vais essayer d’y participer pour voir (d’expérience bon nombre de « tickets discutions/échanges/travail » que j’ai ouvert « meurent » au bout de 12 mois … ceux qui marchent par contre c’est un bug clair → une pr avec peu d’interactions avec les autres)
Il a été question de fusionner les forums il y a quelques mois Forum multilingue
Un seul forum multilingue permettrait déjà de rassembler tous les développeurs, et de n’avoir plus que deux espaces d’échanges (githug + forum) au lieu de 7 actuellement (il y a 6 forums distincts il me semble).
1 « J'aime »
Il s’agirait d’une consolidation importante de cette grande communauté internationale d’utilisateurs et de développeurs.
Salut,
C’est effectivement une bonne idée, mais il faudrait arriver à motiver @jtraulle sur le sujet.
En effet, quelque soit l’outil, on constate que pour obtenir des interactions, il vaut mieux poser du concret plutôt que de l’idée. Et qu’il vaut mieux utiliser l’outil dédié à cela, donc, pour de la proposition de modification de code, d’utiliser les PR (je sais je radote, mais comme j’ai du mal à me faire comprendre, je répète à nouveau).
Les autres développeurs n’hésitent pas à proposer des PR pour des changements et évolutions structurante ou douteuse dans le core, souvent en Draft quand le code n’est qu’à l’état d’expérimentation (cela s’appelle du prototypage, et le prototypage est indispensable dans toute évolution d’architecture).
Le concret rend aussi les discussions plus faciles et permet à chacun de voir de manière moins abstraite la proposition, permettant de mieux estimer l’impact que cela aura sur l’existant, sur les modules externes, de savoir de suite ce que cela casse grâce au résultat de la CTI, d’estimer le coût de la généralisation du proto à l’ensemble du coeur, et de se faire une idée des étapes pour y arriver.
Certains développeurs vont jusqu’à faire une PR draft par étape à franchir (quitte à détruire leur PR draft et la refaire différemment plus tard). Cette pratique de draft par étape est une très bonne pratique, car une idée n’est souvent pas suffisante, il faut aussi voir comment attendre l’objectif porté par l’idée au final. C’est ainsi qu’on peut évaluer l’impact d’une évol d’archi. Sans cela, même sur un projet avec beaucoup de contributeurs, on constate que les retours sur une évolution d’architecture restent, soit faible, soit trop vagues pour être constructif. Ceci n’a rien de surprenant.
Les issues sont plus utilisés pour déclarer les bugs (d’où le nom « Issue ») ou demande de fonctionnalités au sens utilisateur (D’où le nom « feature request ») que pour faire des draft des propositions d’évolutions (ce sont plutôt les PR, en draft, ou final si le proto est au point, pour cela).
Hmmmm au risque de s’éloigner du sujet de ce fil, autre exemple de PR « draft » donc : 18.0 fix links error on dedicated virtualhost and ticket code review by rycks · Pull Request #28446 · Dolibarr/dolibarr · GitHub je n’ai pas non plus vu passer beaucoup de commentaires et surtout je « craint » qu’elle ne se trouve maintenant « trop loin » dans le flux des PR pour qu’elle ait une chance d’être acceptée / validée
Autre exemple pour une PR qui m’intéresse beaucoup plus : je ne participe pas sur github qui me semble trop impersonnel … add extrafield point by frederic34 · Pull Request #28239 · Dolibarr/dolibarr · GitHub ce n’est pas un lieu pour échanger entre humain, c’est une suite de messages automatiques de git bidule git commit et autres informations importantes mais qui n’invitent pas à s’exprimer
nous avons des avis différents sur la question, pour ma part lorsque j’ai besoin de bavarder entre humain avant de lancer une implémentation technique le bon outil c’est le coin de la table, la machine à café, un paperboard, des crayons, des feutres, des post-it …et la version « online » déjà bien moins agréable (au sens nombre de dispositifs permettant d’illustrer ses propos) c’est le forum … ensuite loin après vient l’outil du dev pour moi. Concevoir une solution c’est réfléchir, faire des dessins, collecter des informations, laisser décanter, bavarder à plusieurs, opposer des idées, confronter des points de vues etc.
Tiens, regarde durant un devcamp le temps qu’on passe à coder par rapport au temps qu’on passe à échanger et au final c’est quoi le plus important de ces momens là ?
Bonjour,
Les raisons qui font que c’est séparé ont déjà été exposées précédemment.
Personnellement, outre le fait que je ne suis absolument pas convaincu que cela apporterait un quelconque bénéfice, l’investissement en temps pour réaliser ce genre de modification est lourd et je n’ai malheureusement pas de temps à consacrer à cela.
Voir également la réponse de @eldy plus bas qui résume selon moi parfaitement bien ma façon de voir les choses 
C’est totalement compréhensible.
Cependant il y a a peut-être d’autres personnes qui ont les compétences nécessaires pour faire cela. N’est-ce pas le principe même d’un projet open source de permettre à tout un chacun de participer à l’effort ?
1 « J'aime »
Totalement, et je n’empêche personne de proposer ou de travailler sur quoi que ce soit mais je ne gère pas le projet et ce n’est pas moi qui décide de tout de façons de réaliser ou non une fusion des forums des différentes langues en un seul.
Il me semble que ce type de modification profonde au niveau du projet doit se décider au niveau de l’association Association Dolibarr - Dolibarr ERP CRM Wiki par le @ca-asso.
Par ailleurs, il me semble que certaines communautés Dolibarr ne souhaitent de tout de façon pas voir leur forum fusionné en un seul.
Merci pour ces précisions.
