Bonjour,
je trouve ce projet très enthousiasmant, et pour avoir monter dernièrement un site de vente tout spip à partir du plugin echoppe (ce nom est très bon soit dit en passant), j ai été amené a réfléchir sur ce thème...
J avais même en projet de refaire une version du plugin en spip3 a partir de la fabrique pour le reverser à la communauté, mais c'est un peu énorme, et si un projet collectif se monte, c est vraiment bien mieux... Un tel projet sur spip illustrerait aussi un des incroyable atout de ce systeme, son api ouverte et la possibilité de créer simplement de nouveaux objets aussi totalement heteroclite a priori qu'un produit à vendre....
A ce sujet, on peut bien evidement penser que le projet initial de spip est bien loin de la vente en ligne, du web marchand... a titre personnel c'est également un univers dans lequel je n'avais pas trop envie d'aller, mais j ai créé une première boutique pour un copain qui vendait des produits bio et equitable (un vrai militant, hein ! avec un bonnet péruvien sur la tete et tout, pas un opportuniste...) et je pense maintenant que le problème, c est pas vraiment le commerce, mais la façon de le faire... je pense même qu un plugin "tout spip" de commerce en ligne pourrait être un sacré outil mais aussi un drôle et intéressant concept, un truc assez unique, beau et improbable comme un mammifère qui vole, façon polatouche....
Je me permets de jeter quelques réflexions après avoir lu tout l 'echange ainsi que le wiki... il s agit plus de concepts, d'idées, de plans et de structures...
les objets :
suis totalement convaincu qu il faut des objets propres a la boutique, pas des articles bricolés a coup de champs extra (en plus c est tellement simple et normal avec spip3 et la fabrique)...
les objets :
- categories (rayons du magasin ou on range les produits équivalent des rubriques)
- groupe de produits (ensemble de produits)
- produits (les trucs qu on va vendre, équivalent des articles, la définition du produit est beaucoup plus complexe qu il n y parait de loin)
- option de produit (XXL, rouge, vert...)
- gammes (jardinage, informatique... équivalent des mots clés, permet un classement horizontale des produits en dehors de leurs categories)
Et apres moult reflexion, je me dis qu un "groupe de produits", un "produit", et une "option de produit" sont pratiquement la meme chose... Qu' une option de produit peut a tout moment devenir un produit (si il ne reste lus que des tShirt rose en taille 38, ce n'est plus une option), un groupe de produit est un produit...
Enfin, ces 3 objets partagent pratiquement la même definition, les mêmes champs, la seule difference est une notion hierarchique, une "option de produit" a un pere qui est le produit, un produit peut avoir un pere qui est le "groupe de produit"... Il me semble que si on développe un objet "produit" avec cette idée hiérarchique, on pourrait obtenir quelque chose de très intéressant. Je vois tres bien l utilisation au niveau des boucles du front office, et il me semble que ce concept permettrait de traiter élégamment beaucoup de cas....
le prix :
La notion de prix est super compliquée quand on regarde de pres... Le prix d un produit est flou et tout mou, il peut changer en fonction du contexte, de la date, de la devise, des taxes, des quantites, des remises, des promos.... J ai en tete une idée que je ne maitrise pas forcement tres bien techniquement, mais qui me semble majeure dans l api spip : le pipeline...
J imagine au depart un prix HT... on le met dans un tuyau, sur ce tuyau se branchent des fonctions capables de saisir ce qui passe, de le transformer et de le remettre dans le tuyau... fonction du genre pre-taxe post-taxe pre-devise post-devise pre-reduction post-reduction pre-coupon et aussi bien sur pre-frais-livraison...
Il me semble qu avec une architecture de ce genre on peut ne pas avoir a pre juger de l'avenir, qu on peut développer des petits pipeline de base, libre ensuite les développeurs de rajouter les calculs qu'ils veulent dans les differents points d entrées pour obtenir des trucs spécifiques....
le collissage paquetage
enfin, ne sais pas trop le terme adéquate, il me semble indispensable de pouvoir administrer des "types de paquets", chaque produits peut etre conditionné et livré selon des modalités différentes. Pour certains le critere determinant pour calculer les frais de livraison va etre le poids, d autre le volume, le nb de litre, le nombre de container... je pense que sur chaque produit, il faut pouvoir indiquer le type de collisage ce qui permettra de calculer ensuite son cout de delivrement... ca permettrait egalement de traiter le cas des produits immatériels (telechargement, abonnement... par exemple)
j ai d autres trucs en tete (produits multilingues par exemple).... mais ces 3 points me paraissent les plus important... comment je fais pour participer concrètement ?
cordialement
triton
