Salut!
J'ai un projet un peu fou que j'ai l'intention d'implanter dans SPIP.
Il s'agit d'un site qui contiendra un répertoire de pratiques de
médias alternatifs. Chaque entrée au répertoire doit être composée de
presqu'une vingtaine de champs (localisation, technologie, etc).
Puisque les "articles" de SPIP fournissent un nombre discret et limité
de champs (titre, soustitre, surtitre, etc), il faudra que j'écrive
nécessairement du nouveau code.
L'idée générale est donc d'étendre les fonctionalités du concept
d'article pour y ajouter un nombre arbitraire de champs qui serait
accessibles au travers des squelettes de la même façon que les champs
déjà existants le sont déjà: #TITRE, #TEXTE, mais donc aussi
#NOUVEAU_CHAMP1, #NOUVEAU_CHAMP2, où ces champs ne sont pas
"hardcodés" dans le code PHP ou dans la DB, mais choisis soit à
l'installation ou dans l'interface d'administration de SPIP.
J'ai pensé faire ceci de façon la plus générique possible, et rendre
possible la création d'un nombre arbitraire de champs pour les
articles, pour que ceci puisse être réutilisé par d'autres membres de
la communauté.
Deux approches sont alors possibles.
1- les champs sont insérés dans le #TEXTE de l'article, dans un format
défini et facile à extraire (e.g. PHP serialize() ou un format simple
"champ: valeur\n").
2- les champs "génériques" sont carrément créées dans la BD MySQL, à
l'installation
Le problème avec la seconde approche est que l'on ne veut peut-être
pas que ces champs soient disponibles pour tous les articles mais
seulement un sous-ensemble des articles, par exemple seulement ceux
d'une rubrique. Dans ce cas, la structure de la BD est alourdie sans
raison, et on penche donc vers la première approche.
Mais la première approche n'est pas très propre, et elle risque de
foutre en l'air la compatibilité avec les "vrais" champs #TEXTE de
SPIP.
Étant dans un dilemme difficile, je cherche donc conseil chez les
gourous de SPIP. Avez-vous déjà envisagé une situation semblable?
Quels fichiers de l'architecture de SPIP seraient les plus touchés par
l'une ou l'autre des approches?
Serait-il mieux de créer carrément un nouveau type de "document"
(e.g. "répertoire"), au lieu d'utiliser les articles pour ceci? Est-ce
que ceci serait plus difficile à implanter?
Et surtout: seriez-vous réceptifs à intégrer ce nouveau code à SPIP si
il fonctionne correctement? 
Merci de vos judicieux conseils,
A.
