[SPIP Zone] Fournir des données nombreuses et fixes dans un plugin

Archives Zone
1

Yop,

J'ai un doute, qui m'a effleuré la première fois pour le plugin Devise,
et qui continue à me tarauder pour un besoin similaire.

Pour les auteurs que j'affiche sur un site (plaztika.com), je voudrais
gérer l'info de leur pays, de la subdivision dans le pays
(état pour le mexique, région ou département pour la france, etc.), et
ville.

Pour les attribuer à un auteur, il va de soi que ce sera sous forme
de champ ou de champs dans la table auteurs. Cependant, pour les
données elles-mêmes, ce n'est pas si clair. Que ce soit sur ce site ou
de façon générique sous forme de plugin, plusieurs solutions me
viennent à l'esprit, mais aucune ne me satisfait totalement pour ce
genre de données.

- Tables SQL: a priori pas mal car ça gère une grande quantité de
  données. Cependant, ce sont des données qui sont d'une part a priori
  les mêmes pour tout le monde (les tables pays, subdivision 1, ville),
  d'autre part qui ne vont jamais ou jamais changer, et enfin qui
  ont des noms à traduire. Je parle bien entendu de la définition
  de ces infos, pas de leur attribution à un auteur.

- Mots-clés: ajouter au fur et à mesure les mots-clés dont on a besoin
  pour le site. Bof. Le plus rapide, le moins générique et malin,
  évidemment.

- Fichiers de langue. L'option que j'ai prise pour Devises. A priori
  bien pratique et adéquate. Le problème qu'elle me pose est double:
  d'une part, pour des listes éventuellement très très longues, ça veut
  dire que toutes les données sont en RAM, car c'est un tableau PHP.
  Par ailleurs, c'est compliqué d'établir des relations entre les
  données: ça pourrait pourtant être intéressant de dire que l'état du
  Oaxaca est au Mexique. Certes, si on passe par le code iso 3166,
  l'état du Oaxaca est MX-OAX, la région Lorraine est FR-M et la Drôme
  est FR-26, donc l'info de pays est comprise, mais dans d'autres
  situations la relation c'est plus compliqué, par exemple si on veut
  associer un pays à une devise.

Bref... l'un dans l'autre, le SQL me semble le plus "logique" d'un
côté, mais d'un autre côté je sais pas... fournir dans un plugin non
seulement une structure de table mais carrément son contenu, et qui ne
bougera pas, ça me semble un peu bizarre.

Je me suis posé la question il y a quelques jours pour les devises,
maintenant pour les pays, et d'autres se la poseront ou se la sont
probablement posée avant pour d'autres cas, mais je n'ai pas trouvé de
trace de discussion à ce sujet.

Z'en dites ?
--
davux

2

Bonjour,

Pour l’infos pays (et ses subdivisions), avez-vous regardé du côté du plugin « géographie » qui se trouve sur la zone et qui fait « exactement » ça pour les codes pays, et les régions/départements/communes de France…
Ne serait-il pas mieux d’enrichir cette base?

L’utilité de mettre cela en plugin et en tables SQL serait de permettre la réutilisation de ses infos dans d’autres plugins, donc office de lib générique…

Le 17 février 2010 15:59, davux <da@weeno.net> a écrit :

Yop,

J’ai un doute, qui m’a effleuré la première fois pour le plugin Devise,
et qui continue à me tarauder pour un besoin similaire.

Pour les auteurs que j’affiche sur un site (plaztika.com), je voudrais
gérer l’info de leur pays, de la subdivision dans le pays
(état pour le mexique, région ou département pour la france, etc.), et
ville.

Pour les attribuer à un auteur, il va de soi que ce sera sous forme
de champ ou de champs dans la table auteurs. Cependant, pour les
données elles-mêmes, ce n’est pas si clair. Que ce soit sur ce site ou
de façon générique sous forme de plugin, plusieurs solutions me
viennent à l’esprit, mais aucune ne me satisfait totalement pour ce
genre de données.

  • Tables SQL: a priori pas mal car ça gère une grande quantité de
    données. Cependant, ce sont des données qui sont d’une part a priori
    les mêmes pour tout le monde (les tables pays, subdivision 1, ville),
    d’autre part qui ne vont jamais ou jamais changer, et enfin qui
    ont des noms à traduire. Je parle bien entendu de la définition
    de ces infos, pas de leur attribution à un auteur.

  • Mots-clés: ajouter au fur et à mesure les mots-clés dont on a besoin
    pour le site. Bof. Le plus rapide, le moins générique et malin,
    évidemment.

  • Fichiers de langue. L’option que j’ai prise pour Devises. A priori
    bien pratique et adéquate. Le problème qu’elle me pose est double:
    d’une part, pour des listes éventuellement très très longues, ça veut
    dire que toutes les données sont en RAM, car c’est un tableau PHP.
    Par ailleurs, c’est compliqué d’établir des relations entre les
    données: ça pourrait pourtant être intéressant de dire que l’état du
    Oaxaca est au Mexique. Certes, si on passe par le code iso 3166,
    l’état du Oaxaca est MX-OAX, la région Lorraine est FR-M et la Drôme
    est FR-26, donc l’info de pays est comprise, mais dans d’autres
    situations la relation c’est plus compliqué, par exemple si on veut
    associer un pays à une devise.

Bref… l’un dans l’autre, le SQL me semble le plus « logique » d’un
côté, mais d’un autre côté je sais pas… fournir dans un plugin non
seulement une structure de table mais carrément son contenu, et qui ne
bougera pas, ça me semble un peu bizarre.

Je me suis posé la question il y a quelques jours pour les devises,
maintenant pour les pays, et d’autres se la poseront ou se la sont
probablement posée avant pour d’autres cas, mais je n’ai pas trouvé de
trace de discussion à ce sujet.

Z’en dites ?

davux

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

3

Wed, 17 Feb 2010 16:19:58 +0100, TeddyP:

Pour l'infos pays (et ses subdivisions), avez-vous regardé du côté du
plugin "géographie" qui se trouve sur la zone et qui fait
"exactement" ça pour les codes pays, et les
régions/départements/communes de France... Ne serait-il pas mieux
d'enrichir cette base?

Oui je l'ai vu. Actuellement Géographie est très "franco-centré",
c'est-à-dire qu'il traite les départements et régions spécifiquement,
et ne fournit pas de système plus générique: par exemple pour les états
du Mexique, à moins d'ajouter une autre table spécifique "états du
mexique"...

C'est donc justement dans l'optique de coopérer à ce plugin en le
généralisant que je cherche à poser à plat la question de la meilleure
architecture.

Par ailleurs, comme je l'ai souligné, c'est une question plus générale
qui peut se poser dans d'autres cas, par exemple les devises bancaires,
ou sûrement d'autres situations. De façon générale, je pose finalement
la question des "listes" sous SPIP.

L'utilité de mettre cela en plugin et en tables SQL serait de
permettre la réutilisation de ses infos dans d'autres plugins, donc
office de lib générique...

L'utilité de mettre cela en plugin, oui. En tables SQL, pas
nécessairement, par exemple l'approche par fichiers de langues que
j'ai mentionnée permet aussi la réutilisation, la surcharge, etc. (Je ne
prétends pas que cette dernière approche est meilleure, c'est juste un
contre-exemple.)

--
davux

4

Oui, mais est-ce que les chaînes de langue sont passables en critères de boucles? à mes souvenirs, non… Mais peut-être me trompe-je… :stuck_out_tongue:

A voir et tester donc…

Le 17 février 2010 16:31, davux <da@weeno.net> a écrit :

Wed, 17 Feb 2010 16:19:58 +0100, TeddyP:

Pour l’infos pays (et ses subdivisions), avez-vous regardé du côté du
plugin « géographie » qui se trouve sur la zone et qui fait
« exactement » ça pour les codes pays, et les
régions/départements/communes de France… Ne serait-il pas mieux
d’enrichir cette base?

Oui je l’ai vu. Actuellement Géographie est très « franco-centré »,
c’est-à-dire qu’il traite les départements et régions spécifiquement,
et ne fournit pas de système plus générique: par exemple pour les états
du Mexique, à moins d’ajouter une autre table spécifique « états du
mexique »…

C’est donc justement dans l’optique de coopérer à ce plugin en le
généralisant que je cherche à poser à plat la question de la meilleure
architecture.

Alors, autant le rendre générique zé universel… Une véritable librairie géographique… Mais est-ce que le découpage se fait de la même façon partout…

Par ailleurs, comme je l’ai souligné, c’est une question plus générale
qui peut se poser dans d’autres cas, par exemple les devises bancaires,
ou sûrement d’autres situations. De façon générale, je pose finalement
la question des « listes » sous SPIP.

L’utilité de mettre cela en plugin et en tables SQL serait de
permettre la réutilisation de ses infos dans d’autres plugins, donc
office de lib générique…

L’utilité de mettre cela en plugin, oui. En tables SQL, pas
nécessairement, par exemple l’approche par fichiers de langues que
j’ai mentionnée permet aussi la réutilisation, la surcharge, etc. (Je ne
prétends pas que cette dernière approche est meilleure, c’est juste un
contre-exemple.)

–
davux

5

Le 17 février 2010 16:31, davux <da@weeno.net> a écrit :

Wed, 17 Feb 2010 16:19:58 +0100, TeddyP:

Pour l’infos pays (et ses subdivisions), avez-vous regardé du côté du
plugin « géographie » qui se trouve sur la zone et qui fait
« exactement » ça pour les codes pays, et les
régions/départements/communes de France… Ne serait-il pas mieux
d’enrichir cette base?

Oui je l’ai vu. Actuellement Géographie est très « franco-centré »,
c’est-à-dire qu’il traite les départements et régions spécifiquement,
et ne fournit pas de système plus générique: par exemple pour les états
du Mexique, à moins d’ajouter une autre table spécifique « états du
mexique »…

Spip-geo sur la zone était amené à faire cela …

Mais l’arrivée de « géographie » après a détourné les yeux de beaucoup vers celui là…

Bref …

Je ne relancerai pas un troll type noisetier… mais bon …

++

kent1

6

Le 17 févr. 2010 à 22:30, Quentin Drouet a écrit :

Le 17 février 2010 16:31, davux <da@weeno.net> a écrit :

Wed, 17 Feb 2010 16:19:58 +0100, TeddyP:

Pour l’infos pays (et ses subdivisions), avez-vous regardé du côté du
plugin « géographie » qui se trouve sur la zone et qui fait
« exactement » ça pour les codes pays, et les
régions/départements/communes de France… Ne serait-il pas mieux
d’enrichir cette base?

Oui je l’ai vu. Actuellement Géographie est très « franco-centré »,
c’est-à-dire qu’il traite les départements et régions spécifiquement,
et ne fournit pas de système plus générique: par exemple pour les états
du Mexique, à moins d’ajouter une autre table spécifique « états du
mexique »…

Spip-geo sur la zone était amené à faire cela …

Mais l’arrivée de « géographie » après a détourné les yeux de beaucoup vers celui là…

Bref …

Je ne relancerai pas un troll type noisetier… mais bon …

oué
pis moi je les tuerai tous au profit d’un truc basé sur yql et geoplace.
Mais bon …

Cédric

7

Wed, 17 Feb 2010 22:30:03 +0100, Quentin:

Spip-geo sur la zone était amené à faire cela ...

Cool, je le connaissais pas. Je connais pas l'histoire à laquelle tu
fais allusion, mais chouette initiative pourtant, dommage que ça ait
pas pris.

Ceci dit, en voyant les imports à partir de fichiers CSV, et avant
d'avoir envie d'y contribuer, je continue à me demander si des tables
c'est vraiment un bon modèle pour ce genre de données (liste fixe, a
priori la même pour tout le monde).

Par exemple, quand il y a des changements dans les données (un code
ISO, une dénomination d'État, etc.), les mises à jour vont être
compliquées. En effet, impossible d'écraser la table sur le site des
gens, car ils ont peut-être fait des modifs exprès. De manière
générale, à mon sens les tables c'est pour les données propres à un
site.

Vu comme ça, je pense que la meilleure logique pour ce type de
données est vraiment celle des fichiers de langue, mais le fait de
tout charger en RAM me gêne. Faudrait penser à un mix des deux.

--
davux

8

Le 18/02/2010 00:45, davux a écrit :

Wed, 17 Feb 2010 22:30:03 +0100, Quentin:

Spip-geo sur la zone était amené à faire cela ...

Cool, je le connaissais pas. Je connais pas l'histoire à laquelle tu
fais allusion, mais chouette initiative pourtant, dommage que ça ait
pas pris.

Ceci dit, en voyant les imports à partir de fichiers CSV, et avant
d'avoir envie d'y contribuer, je continue à me demander si des tables
c'est vraiment un bon modèle pour ce genre de données (liste fixe, a
priori la même pour tout le monde).

Par exemple, quand il y a des changements dans les données (un code
ISO, une dénomination d'État, etc.), les mises à jour vont être
compliquées. En effet, impossible d'écraser la table sur le site des
gens, car ils ont peut-être fait des modifs exprès. De manière
générale, à mon sens les tables c'est pour les données propres à un
site.

Vu comme ça, je pense que la meilleure logique pour ce type de
données est vraiment celle des fichiers de langue, mais le fait de
tout charger en RAM me gêne. Faudrait penser à un mix des deux.

Ben nan parce qu'avec cette méthode on peut pas mettre plusieurs données pour une entité : différents codes iso, coordonnées, relations entre les entités (fait parti de...).

Geonames ça a l'air cool !

D'ailleurs ya un plugin qui l'intègre dans Drupal, ya peut-être moyen de s'en inspirer.

Ce qu'il faudrait c'est que les plugins qui ont besoin de données géographiques utilisent les mêmes identifiants unique (code iso ou autre) mais que derrière la BOUCLE(GEOGRAPHIE) puisse utiliser différents backends :
- soit on a installé un plugin qui importe toutes les données dans la base du site, alors la boucle va chercher dedans directement
- soit on a installé un plugin qui intègre Geonames et alors la boucle va en fait appeler le webservice mais renvoyer la même chose

Une même API, plusieurs manières de stocker les données.

--
RastaPopoulos