Il me semble que le débat lancé par Régis n'était pas d'utiliser de connaitre le langage de template (consensus avec Laurent là dessus depuis février il me semble) mais de décliner le système de template PHP pour toute l'application.
Mais peut-être n'ai-je pas tous compris.
Ce sujet, qui n'est évoqué que dans un paragraphe, était une digression.
Juste pour dire que des choses "majoritairement admises" ne sont pas nécessairement "bonnes" ou "parfaites"
Ca tendait aussi à illustrer que derrière le concept mvc, il y a plusieurs philosophies d'implémentation possible.
Si j'ai une couche d'interprétation des tags de template, je rajoute du code, des bugs et du temps machine.
Si les tags sont du php, je rajoute rien.
Mais comme je le précisais juste après, cet aspect, que j'ai évoqué aux hackweeks avec Régis, est parfaitement anecdotique et sans importance réelle.
L'important était après.
Choix des modèles de dev pour préserver la capacité de maintenance (par exemple trop d'abstraction tue la compréhension).
Mais bon, je viens d'un monde où des C++ addicts réinventaient le langage à coup de macros (tu lis le code, c'est tout sauf du C++ natif) et où, aussi quand on codait 40000 lignes en Ada, ma grand-mère pouvait prendre au hasard 50 lignes et décrire grossièrement, rien qu'en lisant le code (sans commentaires), ce que faisaient ces 50 lignes... Le code était littéral, l'abstraction était bien là, mais pour faciliter la compréhension, pas pour l'obscurcir. Par contre Ada était un langage ou on passait plus de temps à réfléchir, puis à aussi à coder. Par contre, rien à débuguer, hors les erreurs de logique. Idem pour la maintenance, tu maintiens modifie un code Ada quasiment en instantané.
On peut finalement faire la même chose dans n'importe quel langage, au prix d'un peu d'effort pour faire les bons choix.
Alors, autant je suis conscient que la séparation évoquée est souhaitable, autant il y a d'autres problématiques évoquées dans cette thread (monolithisme ou modularisation, communication inter modules, etc...) qui me semblent autrement plus fondamentaux.
Il faut trouver la bonne réponse, pour conserver une maintenabilité tout en permettant l'extension de Dolibarr.
Mais, comme je concluais le précédent message, ce que l'on attends aujourd'hui, c'est du fonctionnel : c'est une compta, certaintement des fonctions de stock plus évoluées et certainement aussi un canal de communication standard avec des sites marchands (exemples qui sont revenus souvent aux hackweeks). Les devs souhaitent des choses, les utilisateurs d'autres.
Il y a eu très tard, un soir aux hackweeks, une discussion intéressante (parmi d'autres) sur l'implémentation des variantes stock, certains pensaient qu'il était plus propre de rajouter des tables intermédiaires avec les bonnes relations (j'étais plutôt de ceux là), d'autres pensaient simplification à outrance (simple rajout de champ contenant des codes). C'est un peu le même problème : plus de tables pour un code plus simple ou moins de table pour un code plus complexe.
Ca m'a permis de vérifier que Laurent est toujours pour la solution la plus simple (dans tous les sens du terme), afin de conserver une maintenabilité et des performances. Après tout, Dolibarr étant ce qu'il est (çad sans équivalent sur beaucoup de points), je lui fais, à la toute fin, confiance pour faire les bons choix. D'autant plus que pas mal de ses réflexions vont également dans le sens de mon expérience de dev : simplicité n'est pas simplisme, moins il y a de code, moins il y a de bug, ne mettre de l'abstraction que lorsque ça aide la maintenance, etc...
--
LA SOLUTION à vos problèmes INFORMATIQUES SR Infosystèmes 15, rue du Temple 17310 St Pierre d'Oléron Ile d'Oléron - France Mobile : 06 89 29 88 44 Fixe : 09 54 10 55 60 (appel local) Fax : 09 59 10 55 60 Contact : www.sriviere.tel Site : www.srinfosystemes.fr X509 : www.sriviere.info Skype : stephane.riviere Email : address@hidden