Re: [Dolibarr-dev] Re: [Dolibarr-association] Versions et Roadmap Dolibarr

[Cyrille de Lambert]

Je suis assez d'accord avec l'approche de Régis.
On doit pouvoir faire un ensemble de template pour un type de terminal donné sans toucher au cœur de l'application.
Nous utilisons des système très évolués comme Magento (basé sur Zend) et nous voyons tous les jours que la séparation des couches est vraiment très appréciable et nous offre une souplesse inégalée même si la monté en compétence au niveau dev est un peu plus longue. Sur Prestashop, la séparation des couches est beaucoup moins bien faite pour le backoffice et ça nous occasionne des problème pour étendre certaines fonctions sans toucher au coeur. Une véritable galère dans certains cas même si ça tend à progresser avec les dernières versions. Ça nous occasionne des problèmes importants pour les montées de versions.
Concernant la résolution des bugs, certes, on n'ira pas plus vite. Mais un bon outillage permet de ne pas être plus lent.
D'ailleurs, je n'ai pas bien compris. Je pensais que le système de canvas devait-être déclinée sur tous le système ?
Ça fait également 10 ans que je bosse sur des systèmes MVC (java en premier lieu avec struts) et je trouve qu'un système propre est un véritable plus dans le temps. J'ai vu une différence considérable avec les façons de coder d'antan.
Actuellement, je ne n'aime pas du tous l'inclusion de HTML dans le code (via printf) car je trouve ceci illisible. Un système de template rend la chose beaucoup plus lisible et quelqu'un comme moi ira beaucoup plus lentement pour programmer ce type de code par manque d'habitude.
En ce qui me concerne, je passerais 75% de moins en temps sur un code avec template. Il est vrai que nous sommes tous différents et que ce qui peut paraitre simple pour l'un peut paraitre compliqué pour l'autre (ex : nos discussions sur les produits déclinables ou je trouvais que ma façon de voir est beaucoup plus simple d'approche car beaucoup moins de code à générer).
Tout est une question de point de vue et nous n'avons pas forcement la même expérience.
Malgré tous, Laurent, merci énormément pour toutes les évolutions positives que tu as apporté à l'application ... Je sais que nous n'en serions pas là aujourd'hui sans toi. Même s'il y aura peut-être des consensus à trouver si le nombre de contributeurs augmente avec le temps. Et ce sera nécessaire pour que l'application prenne de l'ampleur.


Cyrille

Le 15/12/2010 19:36, Laurent Destailleur a écrit :

Le 15/12/2010 18:10, Régis Houssin a écrit :

allez j'en remet une couche ;-)

Si on veut trop transformer Dolibarr en framework plutot qu'en ERP,
mieux vaut se tourner sur des ERP à archi lourdes et ultra
paramétrables comme Compiere qui sont prévus pour cela.

je le considère de plus en plus comme un framework (ou un socle)
permettant de développer des modules qui viendront enrichir le terme
ERP/CRM !

car nous avons accolé les termes ERP/CRM à Dolibarr et il manque pas mal
de choses pour que ces termes soit valide.

c'est pour cela qu'il faut à tout pris rendre le code plus ouvert et
plus souple une bonne fois pour toute afin de rendre les modules
autonomes avec des entrées/sorties qui permettrons aux autres modules
(internes ou externes) de pouvoir dialoguer sans avoir besoin
d'intervenir dans le code.

ton système MVC tout en un dans une page te parait simple mais devient
vite compliqué quand tu veux apporter ta brique, le fait de séparer
chaque partie dans des fichiers différents (métier, control, view)

Sur le modèle actuel, Bug corrigé en 1mn
Avec les templates, je mettais 5 mn pour corriger le meme bug. Alors que
je venais de le corriger juste avant donc la réponse était toute trouvée.

Soit perte de productivitié de x5. Donc je suis pas sur que ce soit
vraiement plus clair.
Et pour travailler dans le sujet depuis des annnés et faire des études
de productivité, le comparatif a eu le temps d'etre rodé: Le ratio de x5
est également confirmé, meme si c'est sur du java, PHP et ses include
et le modele de canvas est comparable à du JSP et ses include et les
canvas a de l'IOC.

Donc cela va etre dur de me convaincre sur ce sujet la car je ne crois
que les chiffres et cela fait des années que je chiffre des ratio de
maintenance sur les frameworks et les patterns de développements.

Autre exemple, en hackweek, on a mis une 40mn a trouvé un bug qu'il
aurait fallu moins de 1mn avec un pattern MVC normal.

permettra d'y voir plus clair.


Cordialement,



_______________________________________________
Dolibarr-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev

_______________________________________________
Dolibarr-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev