Davux
Salut,
Il y a 4 plugins sur la zone qui touchent à des choses voisines :
- Produits :
http://zone.spip.org/trac/spip-zone/browser/_plugins_/produits- Prix :
http://zone.spip.org/trac/spip-zone/browser/_plugins_/prix/- Montants :
http://zone.spip.org/trac/spip-zone/browser/_plugins_/montants/- Devise :
http://zone.spip.org/trac/spip-zone/browser/_plugins_/devise/
http://www.spip-contrib.net/Plugin-DevisePremier point : en regardant les 3 premiers, je ne comprends pas bien
comment ils interagissent ensemble. Est-ce que quelqu’un voudrait
expliquer comment tout ça s’articule ? Je crois qu’ils sont séparés
exprès, et travaillent ensemble, mais je n’ai pas suivi.Ensuite, en ce qui concerne le plugin Devise dont je suis l’initiateur,
il fournit les noms traduits des devises mondiales ainsi que quelques
outils pour les manipuler.
Ce plugin ajoute aussi (pour mes besoins à la base) un champ « devise
préférée » sur les auteurs, mais en vrai il serait intéressant d’avoir
des devises sur tous les objets, ce qui rendrait service aux gens qui
veulent :
- continuer à avoir des devises par auteur,
- mettre des devises sur les produits en plus du montant (logique).
- sur les articles, les rubriques... la devise de la rubrique 0
pouvant servir de « devise du site » (besoin exprimé par Gildas
Cotomale).- sur les autres objets du core, et les futurs objets en général suivant
les besoins (si marcimat veut se lancer dans le commerce de chats par
exemple).À la lumière de ces réflexions, je me demande comment faire évoluer ou
brancher Devise avec ces plugins. Par exemple, s’il y a une table de
montants générique pour tous les objets, peut-être qu’y ajouter une
colonne devise avec juste le code ISO serait utile, avec un « utilise »
sur Devise pour les gens qui voudraient faire un usage plus poussé de
cette information.Par exemple, je ne sais pas si techniquement c’est possible que Devise
déclare de son côté la table « spip_montants » (la même que celle du
plugin Montants) avec évidemment un champ devise mais également
id_montant, objet, id_objet, de façon à ce que chacun des deux plugins
soit utilisable seul, tout en pouvant fonctionnant ensemble.Et aussi, peut-être que vous avez prévu de fusionner à termes certains
de ces plugins, et/ou que Devise devrait fusionner avec l’un d’entre
eux ? Je ne pense pas, car la manipulation des devises peut devenir
assez poussée et encombrerait plein de gens qui n’en ont pas l’usage,
mais c’est vrai aussi qu’à trop fragmenter les choses on devient
contre-productif... Donc à voir comment on peut utiliser la Puissance
de SPIP pour faire rouler tout ça.Enfin voilà... je laisse les auteurs des plugins en question et les
pros en Puissance de SPIP intervenir.
RastaPopoulos
Le 02/09/2011 03:26, davux a écrit :
Premier point : en regardant les 3 premiers, je ne comprends pas bien
comment ils interagissent ensemble. Est-ce que quelqu’un voudrait
expliquer comment tout ça s’articule ? Je crois qu’ils sont séparés
exprès, et travaillent ensemble, mais je n’ai pas suivi.Ouiiiiiiiiii ?
Le plugin Prix est une API centrale commune à tout ce qui pourrait toucher à de l’argent. Des fonctions uniques quelque soit le type d’objet permette de récupérer le prix hors taxe ou le prix taxé d’un objet. Le principe est que chaque objet éditorial *peut* être étiqueté d’un prix. Sinon son prix vaut 0.
inc_prix_dist($type_objet, $id_objet)Pour implémenter cela, pour un cas simple, il suffit que l’objet ait un champ « prix_ht » ou un champ « prix » dans sa table.
Pour un cas plus complexe (souvent), il faut que l’objet ait un fichier « prix/montruc.php » avec dedans une fonction qui dit quel est son prix HT, et une fonction qui dit quel est son prix taxé (si ça a un sens, sinon prix TTC = prix HT).
Pour les deux fonctions (prix et prix_ht) il y a un pipeline qui permet de modifier le comportement (un plugin externe qui ajoute une taxe supplémentaire par ex).
Le plugin ne gère pas les devises volontairement, avec l’euro par défaut, mais le but est bien que SI le plugin devise existe on puisse l’utiliser (à faire).
Le plugin Prix ne s’occupe que d’indiquer UN nombre associé à un objet, sans indiqué dans quelle devise c’est. Ça c’est au plugin qui utilise Prix de le dire (par exemple Produits devrait permettre de configurer que les prix des produits sont donnés en Yen par défaut).
Ensuite ce sont aux plugins utilisant Prix de faire un peu ce qu’ils veulent avec ce nombre. En effet, pour chaque objet l’utilisant ça peut être un comportement différent, ce n’est pas à l’API centrale de le dire.
Le plugin Montant c’est pas moi, mais je crois que le but est de donner un prix *par défaut* à des types d’objets ou des branches précises de l’arbo quand c’est pour des rubriques ou articles.
À mon avis le plugin Devise doit rester bien séparé, car peut servir à de multiples choses (même quand on a pas d’objets avec des prix). J’ai essayé de construire tout un début de framework e-commerce sur ce principe modulaire.
Pour l’instant je ne sais pas si la jonction se ferait en priorité entre Devise et Prix, ou entre Devise et les plugins utilisant Prix.
Azerttyu a aussi un cas où chaque objet à PLUSIEURS prix dans plusieurs devises, car pour chaque monnaie les prix sont adaptés et non pas calculés automatiquement à partir d’une seule. Et ça pour l’instant le plugin Prix ne le prévoie pas. Donc ça serait peut-être à lui de le prévoir dans l’API, pour qu’on puisse demander le prix de l’objet patate-34 dans la devise XX...
Bref tout ceci est TRÈS complexe, mais oui : dans l’idée ton plugin était bien prévu dès le départ pour venir se brancher quelque part !
Dans un premier temps il peut déjà s’occuper de la fonction « prix_formater » :
http://zone.spip.org/trac/spip-zone/browser/_plugins_/prix/prix_fonctions.php#L46Celle-ci affiche un nombre donné en ajoutant la devise (euro pour l’instant) et donc le plugin Devise si ya une notion de « devise par défaut pour un site » (différent de rubrique 0 car on peut avoir un site sans rubriques mais avec un autre objet ayant un prix) devrait remplacer « euro » par celle-ci.
Voilà j’ai écrit tout ça un peu en bordel, alors n’hésite pas à poser des questions plus précises sur tel ou tel point.
Gildas Cotomale
> Il y a 4 plugins sur la zone qui touchent à des choses voisines :
>
> - Produits :
> http://zone.spip.org/trac/spip-zone/browser/_plugins_/produits
> - Prix :
> http://zone.spip.org/trac/spip-zone/browser/_plugins_/prix/
> - Montants :
> http://zone.spip.org/trac/spip-zone/browser/_plugins_/montants/
> - Devise :
> http://zone.spip.org/trac/spip-zone/browser/_plugins_/devise/
> http://www.spip-contrib.net/Plugin-Devise
>
> Premier point : en regardant les 3 premiers, je ne comprends pas bien
> comment ils interagissent ensemble. Est-ce que quelqu’un voudrait
> expliquer comment tout ça s’articule ? Je crois qu’ils sont séparés
> exprès, et travaillent ensemble, mais je n’ai pas suivi.
>Je ne connaissais pas « montan »... Et prix, d’après ce que j’avais
compris, ne s’occupe que du montant brut (le nombre quoi) en tenant
compte de paramètres modifiant sa valeur nette (donc remises et taxes)
Pour l’interaction ensemble, je dirai qu’il n’y a encore rien de
cocret ? Mais l’idée de briques distinctes est très bonne pour avoir
un « framework » à la fois modulaire, souple et facile à maintenir.
C’est un exemple complexe et je crois que c’est la bonne voie que
d’avoir une vision (des idées) de base et du code simple et
fonctionnel qui va murir en fonction des besoins et des retours
d’usage.> Ensuite, en ce qui concerne le plugin Devise dont je suis l’initiateur,
> il fournit les noms traduits des devises mondiales ainsi que quelques
> outils pour les manipuler.
> Ce plugin ajoute aussi (pour mes besoins à la base) un champ « devise
> préférée » sur les auteurs, mais en vrai il serait intéressant d’avoir
> des devises sur tous les objets, ce qui rendrait service aux gens qui
> veulent :
> - continuer à avoir des devises par auteur,
> - mettre des devises sur les produits en plus du montant (logique).
> - sur les articles, les rubriques... la devise de la rubrique 0
> pouvant servir de « devise du site » (besoin exprimé par Gildas
> Cotomale).Euh... la devise globale peut ne pas s’appliquer à toutes les
rubriques mais à d’autres objets... (légère nuance selon la façon dont
on utilise le site)> - sur les autres objets du core, et les futurs objets en général suivant
> les besoins (si marcimat veut se lancer dans le commerce de chats par
> exemple).
>
> À la lumière de ces réflexions, je me demande comment faire évoluer ou
> brancher Devise avec ces plugins. Par exemple, s’il y a une table de
> montants générique pour tous les objets, peut-être qu’y ajouter une
> colonne devise avec juste le code ISO serait utile, avec un « utilise »
> sur Devise pour les gens qui voudraient faire un usage plus poussé de
> cette information.
>
> Par exemple, je ne sais pas si techniquement c’est possible que Devise
> déclare de son côté la table « spip_montants » (la même que celle du
> plugin Montants) avec évidemment un champ devise mais également
> id_montant, objet, id_objet, de façon à ce que chacun des deux plugins
> soit utilisable seul, tout en pouvant fonctionnant ensemble.
>Sur ce point, je pense que c’est à chaque plugin de gérer son couple
montant+devise sur ces objets (avec préférentiellement, dans les cas
simples, les champs prix_ht ou prix_ttc et devise —donc il faut une
certaine nomenclature ...sur laquelle les APIs peuvent s’appuyer...
mais avec la possibilité de faire plus complexe)La table que tu proposes ressemble à une table de liaison pour des
objets partageant les mêmes montants et devises ; donc je l’appellerai
plutôt « spip_montants_devises_liens » par exemple. Ce genre de table
permet en effet à n’importe quel objet de pouvoir utiliser les deux
sans devoir se réinventer ses liaisons propres. C’est donc une bonne
idée.> Et aussi, peut-être que vous avez prévu de fusionner à termes certains
> de ces plugins, et/ou que Devise devrait fusionner avec l’un d’entre
> eux ? Je ne pense pas, car la manipulation des devises peut devenir
> assez poussée et encombrerait plein de gens qui n’en ont pas l’usage,
> mais c’est vrai aussi qu’à trop fragmenter les choses on devient
> contre-productif... Donc à voir comment on peut utiliser la Puissance
> de SPIP pour faire rouler tout ça.
>Volià, tu l’as bien dit : il faut que chaque fonctionnalité puisse
être séparée et que chacun puisse faire sa cuisine selon ses besoins
:) Ce qu’il faut n’est pas de fusionner mais de s’accorder (sur
l’usage de pipelines, les tables communes, une nomenclature, etc.)
Gildas Cotomale (once again)
> [...]Ah ! RastaPopoulos, ton intervention va exactement dans le sens de mes
idées ! Et j’aime bien la philosophie du plug Prix (que je n’ai pas
encore eu à mettre en œuvre, chose qui ne saurait tarder)> Dans un premier temps il peut déjà s’occuper de la fonction « prix_formater »
> :
> http://zone.spip.org/trac/spip-zone/browser/_plugins_/prix/prix_fonctions.php#L46
>
> Celle-ci affiche un nombre donné en ajoutant la devise (euro pour l’instant)
> et donc le plugin Devise si ya une notion de « devise par défaut pour un
> site » (différent de rubrique 0 car on peut avoir un site sans rubriques mais
> avec un autre objet ayant un prix) devrait remplacer « euro » par celle-ci.Ça me rappelle une petite discuss sur contrib il y a peu : tu y
apportes un certain éclairage indirectement. :-)
Davux
02/09/2011, RastaPopoulos :
> Azerttyu a aussi un cas où chaque objet à PLUSIEURS prix dans
> plusieurs devises, car pour chaque monnaie les prix sont adaptés et
> non pas calculés automatiquement à partir d’une seule. Et ça pour
> l’instant le plugin Prix ne le prévoie pas. Donc ça serait peut-être
> à lui de le prévoir dans l’API, pour qu’on puisse demander le prix de
> l’objet patate-34 dans la devise XX...Je pensais faire une fonction de conversion d’une devise à l’autre dans
le plugin Devise, en utilisant des sources via internet (et un cache).
Mais c’est complètement vrai que parfois le prix dans une devise et
dans une autre ne dépend pas uniquement d’une conversion mathématique
mais aussi d’un tas de trucs. Par exemple, plein de sites acceptant
Bitcoin te font un prix plus intéressant si tu paies en Bitcoins, pour
promouvoir l’usage de la monnaie. Inversement, certains pays pénalisent
l’utilisation du dollar US, etc. Peut-être que la fonction de
conversion pourrait se faire dans le plugin Devise, mais avec un
pipeline pour pouvoir influer sur ces conversions au cas par cas.> Dans un premier temps il peut déjà s’occuper de la fonction
> « prix_formater » :
> http://zone.spip.org/trac/spip-zone/browser/_plugins_/prix/prix_fonctions.php#L46Je suis justement en train de préparer dans Devise une fonction qui
gère les symboles monétaire, donc je garderai ce besoin en tête au
passage. Le formatage des prix est complexe car il faut prendre en
compte la locale de la personne qui lira le prix pour déterminer les
séparateurs de décimales et de milliers, et il faut prendre aussi en
compte la position du symbole monétaire, sujet lui-même bien plus
complexe qu’il n’en a l’air. Et les fonctions qui font soi-disant ça
(en tout cas le formatage de monnaie) en PHP sont trop simplistes pour
être utilisables.Merci pour le reste des infos, il faudrait faire une section
« gestion des thunes » sur contrib et documenter un peu tout ça pour ne
pas perdre de vue les problématiques.