Re: [LibreAsso] Les Centres Sociaux, le Libre et les lobbies ...

[Dominique Chabord <dominique.chabord AT sisalp.org>]

Le 18 décembre 2017 à 18:02, Fabien BOURGEOIS <fabien AT yakulu.net> a écrit :

> L'approche est en effet assez différente. À ma connaissance, il n'existe pas
> (je me trompe peut-être) de solution clé-en-main pour avoir une boutique
> avec Tryton.

Oui, soit le code libre existe parce qu'on veut un boutique identique,
soit il faut modifier.

> Il faut par conséquent passer par un framework et du sur
> mesure.

C'est le principe même des sites Flask. Django procède du même
principe. Le principe du micro-framework est en cours d'adoption.
Il n'y a pas de limite nette entre standard et sur mesure, le standard
étant un sur mesure utilisé deux fois.
Le spécifique est plus accessible sur ce type de solution, c'est du
sur mesure qui ne sera pas réutilisé.
Après il faut comparer coût, rapidité et stabilité, sachant que
l'expertise technique des micro-framework est encore rare.


> Odoo intègre directement les fonctionnalités de CMS et de boutique.

>
> Cela a des avantages

> (interface unique,

je ne crois pas. Dans Odoo l'interface e-shop n'est pas celle du back-office
Il est important de pouvoir différencier les thèmes quand on a
plusieurs boutiques, sans modifier celui du back-office.

> lien direct,

Le shéma des URL ( ?) est implémenté sur Tryton, je ne sais pas sur Odoo

> synchronisation de
> fait,

Je ne vois pas de différence sur ce point. Il n'y a pas de duplication
de données dans les deux cas.


> fonctionnalité incluse et donc fonctionnelle pour chaque version)

Je ne m'étais pas posé la question. Je ne vois pas pourquoi il
faudrait modifier la boutique quand on monte de version sur Tryton
mais il doit y avoir des cas où c'est nécessaire. Vue de l'application
web, Tryton est une bibliothèque.

> et
> des inconvénients (une application spécialisée peut faire mieux qu'une
> application généraliste,

je dirais plutôt que spécialiser un application gérée par un progiciel
est plus compliqué et coûte à chaque mise à jour.
Il est difficile de standardiser une boutique.


> on peut préférer une isolation entre la base de
> production quotidienne et la partie publique etc).

Partiellement vrai.
Le front-end a des droits limités mais il manipule directement des
objets Tryton, donc s'il est compromis, il doit pouvoir faire des
dégâts quand même.


>
> À noter que dans l'écosystème OpenERP/Odoo, il y a aussi des connecteurs
> pour des solutions comme Magento, et d'autres approches.

Puisque tu en parles, l'histoire explique bien la technique :
Le tout premier auteur de ces connecteurs OpenERP les a portés à
l'époque sur Tryton, le code est resté en l'état :
https://github.com/openlabs/trytond-magento

Cet auteur a ensuite expliqué à la communauté Tryton pourquoi ce
n'était pas une bonne stratégie ;-) et a démontré le premier
l'intégration Flask Tryton dans une solution de "super boutique"
appelée Nereid : https://github.com/openlabs/nereid

En croisant sa démarche (visionnaire, amha) avec la stratégie KISS de
Tryton on arrive au résultat actuel. On voulait limiter l'impact de la
boutique sur le modèle de données de l'ERP et garder une modularité.

Pendant ce temps, Odoo a reconstruit ses vues sur un framework web
spécifique, adoptant une approche opposée.

Il reste cependant pas mal à faire chez Tryton pour disposer de
boutiques génériques en kit, mais ça avance, grâce aux pionniers qui
financent cette partie du projet. Pour une verticalisation
"Association" en investissement mutualisé, le modèle technique est
plutôt simple.