+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:
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).
@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).
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 ?
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.
un exemple vraiment concret d’une PR avec un échange qui finalement ne sert à rien d’après moi : codespell and datee by rycks · Pull Request #28828 · Dolibarr/dolibarr · GitHub
Question dans l’assemblée qui arrive à voir le contenu des échanges qu’il y a eu ? je n’arrive même plus à déplier le bidule pour voir les 9 échanges de la conversation alors que j’étais partie prenante…
ces échanges deviennent invisibles, inaccessibles, non indexés par un moteur de recherche (interne à github / au projet ou plus large du genre goo***) … bref pour moi c’est l’archétype du truc qui sert à rien dans le sens partage de l’information et « pédagogie » sur le projet
peut-être que je me trompe mais je pense vraiment que cette PR va mourir et disparaître, il n’en restera rien et le temps passé à son sujet ne servira probablement à personne d’autre alors que les échanges qu’il y a eu à son sujet pourraient servir à d’autres développeurs qui vont se heurter comme moi à codespell qui débarque sur develop et qui interdit certains commit (en tout cas c’est ce que j’ai vécu ce matin et qui m’a fait perdre 30 minutes et provoquer cette PR finalement refusée car « peut mieux faire » 
)
Note: j’ai mis 10 minutes à trouver qu’il faut cliquer sur « show resolved » pour déplier les échanges … vraiment une fois qu’on le sait c’est « évident » …
Bonsoir,
concrètement voilà ce que je vais proposer d’ici peu:
je ne sais pas si je vais avoir le temps de rajouter la notion de middleware au passage et faire en sorte que le routeur soit un objet et non une fonction « plate » … mais bon en tout cas ça me semble assez propre pour construire sur ce genre de concept.
pour info le AuthController ne fait que vérifier les objets User de dolibarr avec login/pass et génère un JWT (token) pour l’application, sans plus pour l’instant.
Et les autres contrôleurs par exemple MenuController est là pour piloter ce qui s’affiche sur l’interface du smartphone (page d’accueil / le menu)…
DlcController lui fait le passe-plat entre l’api json CRUD pour smartphone et les objets dolibarr. Pour ne pas perdre en route les développeurs d’applications je me suis calé sur les habitudes structurantes de laravel dans laquelle on trouve par exemple ceci:
PSR-4 is done sur cette partie en tout cas, vous voulez offrir un nouvel objet à votre application smartphone ? il faudra créer un controleur comme ceci:
Et ensuite définir les points d’entrées que vous voulez dans le fichier api.php
Point d’étape avec le cas concret de l’application SmartDLC :
En résumé: il y a une api spécifique entre l’application smartphone et le serveur, cette API est implémentée « dans l’idée » de Laravel, j’espère ne pas avoir trop dénaturé cette approche d’ailleurs … et ensuite cette API fait du « collage » avec le code dolibarr
Normalement nous nous lançons sur le redev de SmartLivraison (@mi973 c’est pour toi entre autre) pour basculer sur cette pile technologique …les résultats devraient être sans comparaison avec mes précédents itérations …
