Bonjour,
attention message qui risque de partir en live, je compte sur vous pour que ça ne soit pas le cas. J’ai absolument besoin de mettre tout ça sur un espace de commentaires AVANT de faire éventuellement « n’importe quoi » …
Vous le savez peut-être mais nous sommes en train d’avancer sur GIFF Socle mobile - Decidim pour Dolibarr … il faudrait arriver à mobiliser assez de monde pour atteindre le budget mais ce n’est pas le sujet du jour.
AVANT d’implémenter des choses, j’aimerais acter le fait qu’il y a des incohérences dans dolibarr et vous informer que je ne veux pas continuer dans ces incohérences et que je souhaite mettre à profit ce « nouveau projet » pour tenter de remettre des choses en ordre.
CONSTATS multiples.
via le module builder si je créé un module MyModule et deux objets MyObj et MyTop et que je demande à avoir une API, bien que le constructeur d’api soit dans l’onglet objet le fichier est global au module. 1ere incohérence, d’autant plus que tout le code du coeur de dolibarr est 1 objet = 1 api (exemple Facture, Societe etc.).
le nom du fichier est class/api_mymodule.class.php, la classe définie dans le fichier est MyModuleApi, autre incohérence, le nom du fichier n’est pas raccord avec le nom de la classe (api_ prefixe → Api suffixe)
si j’ai le malheur de cliquer sur « + » pour générer le code php pour MyTop le fichier php a deux fonctions pour chaque objets, gros bug du module builder mais surtout grosse faille de conception / cloisonnement / modèle objet
au niveau base de données, MyObj est stocké dans une table mymodule_myobj … mais la classe est simplement myobj résutlat si deux modules dolibarr ont un objet « Toto » il entre en collision dans l’espace code (PHP) mais pas SQL (ouf c’est déjà ça). → voir un autre fil sur le forum à propos des namespaces / collisions / composer
Comme je vais proposer que le module builder génère du code pour préfabriquer une interface dédiée pour mobile (PWA) je ne veux pas tomber dans les mêmes incohérences … et continuer à faire du code dont on sait qu’il n’est pas clean qu’il est compliqué à comprendre car plein de petites incohérences de ce genre.
(pré-requis) pour qu’une PWA fonctionne il faut une API, la PWA échange les données avec le serveur dolibarr via une API
PROPOSITIONS et appels à commentaires
création d’un espace de nom lors de la création d’un module dolibarr, ainsi MyObj serait dans \MyModule\MyObj ce qui permet de retrouver une certaine cohérence vis à vis de la base de données à moindre frais
création d’autant de fichiers d’api qu’il y aura d’objets en respectant un plan de nommage des fichiers / répertoires cohérent par rapport aux noms des objets (attention je propose tout simplement de commencer à implémenter PSR-4: Autoloader - PHP-FIG au sein des modules, ça ne peut pas faire de mal)
autant de contrôleurs que d’objets de base, MyModule/Api/Controller/MyObjController.php est le fichier qui contient la classe MyObjController qui offre l’api d’accès à l’objet MyObj … et on commence ainsi à avoir un début de MVC
Les discussions sont ouvertes, en résumé et en mettant les pieds dans le plat (ma marque de fabrique) est-ce qu’on saisit l’opportunité de prendre un petit virage où on continue de faire du code que je qualifie de « à l’ancienne » ? Mon seul objectif est de contribuer au projet dolibarr et d’accompagner du mieux possible ce magnifique projet mais je veux avancer de manière transparente et pas balancer un paquet de code d’un coup. Je compte sur vous pour m’aider à réfléchir et à faire les choses correctement.
Je travaille justement sur un module (interne), avec un besoin au niveau de l’API et de la gestion des objets. Il m’en faut deux comme dans ton exemple.
Je me suis retrouvé limité par les mêmes difficultés que celles que tu mentionnes. Tout cela ne me paraît donc absolument pas incohérent, bien au contraire.
Je vais suivre le sujet de près. Merci d’avoir soulevé la question.
En fait comme le module builder fait un seul fichier j’ai imaginé/déduit que les développeurs voulaient voir un point d’entrée API par module et non par objet de module …
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 ?
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.
« 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).
