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

[Laurent Destailleur]

Le 15/12/2010 21:00, Cyrille de Lambert a écrit :
> 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.

C'est bien aussi ma position.
La différence repose sur la maniere de faire. Faire simple parce qu'on
peu avoir le meme résultat qu'en faisant compliqué.

> 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.

En effet, c'est une approche de type IOC (Inversion Of Control), très
mauvaise pour la maintenance et la compréhension du code. Des simples if
suffisent à changer les classes plutot que l'utilisation d'IOC qui rende
le code abstrait.

 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
> 
> 
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/dolibarr-dev