Les champs EXTRA : l’administrateur peut définir une liste de champs qui étendra la base de données des articles, permettant ainsi d’utiliser SPIP pour des sites gérant des données structurées (catalogues, projets, ...).
Aujourd’hui les articles ont de nombreux champs par défaut : chapo, descriptif, ps, surtitre... Ces champs ne sont fondamentalement pas différents de champs & ;amp;quot ;extra& ;amp;quot ; qui auraient été activés à la livraison de SPIP. Il serait bon d’harmoniser les deux catégories de champs (extra / par défaut).
Comment implémenter les champs extra ? Trois méthodes possibles :
Un tableau sérialisé : la plus souple et la plus simple à mettre en place. Garantit la compatibilité entre toutes les bases. Peut poser problème si on veut un accès & ;amp;quot ;brut& ;amp;quot ; aux champs en-dehors de SPIP (est-ce désirable ?).
Un champ par ligne, dans une table séparée : raisonnablement simple, mais complique un peu les accès à la base. Voir si cela s’intègre facilement dans l’espace public (calcul des squelettes). Voir si cela ne pose pas de problèmes de performances sur de gros sites (imaginons un million d’articles avec cinq champs chacun : cela fait 5 millions de lignes dans la table).
Un champ par colonne : rend les bases de données incompatibles deux à deux. A proscrire, probablement.
PiiF dit : J’étais assez réticent sur l’idée d’avoir une table «champ/objet spip/valeur» mais c’est la meilleure. Il faudrait même une table des champs extra existants (table «id extra / type d’objet spip / condition / type de champ / nom du champ») et une table des valeurs de champs (table «id champ / id objet spip / valeur»). Comme ça, on peut facilement faire évoluer la façon de lier un extra à une liste d’objets (par rubrique, mot clé ou autre).
1. Une table maître, spip_extras, contient les différents champs configurés par le webmestre. Les champs de cette table sont :
& ;amp;lt ;code& ;amp;gt ;objet& ;amp;lt ;/code& ;amp;gt ; : le type d’objet auquel s’applique ce champ (valeurs possibles : articles, breves, rubriques...) & ;amp;lt ;code& ;amp;gt ;nom_champ& ;amp;lt ;/code& ;amp;gt ; : le nom informatique du champ (exemple : texte, chapo, prix, licence...) & ;amp;lt ;code& ;amp;gt ;titre& ;amp;lt ;/code& ;amp;gt ; : le titre affiché dans les formulaires d’édition & ;amp;lt ;quote& ;amp;gt ;(NicolasHoizey : Comment gérer dans ce cas le multilinguisme de l’interface ? Autant avoir des chaînes de langue du type & ;amp;lt ;code& ;amp;gt ;libelle_nom_champ& ;amp;lt ;/code& ;amp;gt ; peut-être ...)& ;amp;lt ;/quote& ;amp;gt ; & ;amp;lt ;code& ;amp;gt ;descriptif& ;amp;lt ;/code& ;amp;gt ; : un descriptif optionnel pour les formulaires d’édition & ;amp;lt ;code& ;amp;gt ;type& ;amp;lt ;/code& ;amp;gt ; : un type parmi les possibilités prédéfinies (exemple : grand_texte, texte_moyen...) & ;amp;lt ;code& ;amp;gt ;detail& ;amp;lt ;/code& ;amp;gt ; : des informations supplémentaires sur le type, si nécessaire (par exemple, les différentes alternatives pour une liste déroulante) ; stockées sous forme de tableau sérialisé (clé =& ;amp;gt ; valeur) & ;amp;lt ;code& ;amp;gt ;important& ;amp;lt ;/code& ;amp;gt ; : si le champ est important ou non & ;amp;lt ;code& ;amp;gt ;ordre& ;amp;lt ;/code& ;amp;gt ; : entier définissant l’ordre d’affichage dans l’espace privé & ;amp;lt ;code& ;amp;gt ;code_squelettes& ;amp;lt ;/code& ;amp;gt ; : le code à utiliser dans les squelettes (sans # : par exemple TEXTE, PS...) & ;amp;lt ;quote& ;amp;gt ;(NicolasHoizey : pourquoi ne pas utiliser la même chose que & ;amp;lt ;code& ;amp;gt ;nom_champ& ;amp;lt ;/code& ;amp;gt ;, simplement en majuscules ? Antoine : par défaut oui, mais dans certains cas où le #BIDULE existe déjà, il faudra désambiguïser (par exemple #POINTS, etc.) NicolasHoizey : peut-être en ajoutant & ;amp;lt ;code& ;amp;gt ;EXTRA_& ;amp;lt ;/code& ;amp;gt ; devant, alors, pour lever toute ambiguité.)& ;amp;lt ;/quote& ;amp;gt ; ?? & ;amp;lt ;code& ;amp;gt ;condition& ;amp;lt ;/code& ;amp;gt ; : à quels ids s’applique ce champ, sur le principe des squelettes : -NN, =NN... ou des conditions inteprétables en PHP, du genre ($id& ;amp;gt ;54)& ;amp;amp ;& ;amp;amp ;($id& ;amp;lt ;44) — ThomasNoel
2. Des tables de données, gérant chacune un type d’objets : spip_articles_extras, spip_rubriques_extras, etc. Par exemple, pour spip_articles_extras :
& ;amp;lt ;code& ;amp;gt ;id_article& ;amp;lt ;/code& ;amp;gt ; : id_article auquel se rattache le champ & ;amp;lt ;code& ;amp;gt ;champ& ;amp;lt ;/code& ;amp;gt ; : nom du champ (correspond au & ;amp;lt ;code& ;amp;gt ;nom_champ& ;amp;lt ;/code& ;amp;gt ; de la table maître) & ;amp;lt ;code& ;amp;gt ;valeur& ;amp;lt ;/code& ;amp;gt ; : la valeur du champ (format texte & ;amp;quot ;longblob& ;amp;quot ;)
& ;amp;lt ;quote& ;amp;gt ;(NicolasHoizey : Je pense qu’il faudrait mieux une seule table & ;amp;lt ;code& ;amp;gt ;spip_extras& ;amp;lt ;/code& ;amp;gt ; et un champ & ;amp;lt ;code& ;amp;gt ;objet& ;amp;lt ;/code& ;amp;gt ; en plus. Antoine : pas génial, car moins optimisable au niveau SQL : par exemple un site où la présence de 15000 articles ralentirait une recherche parmi 30 mots-clés. NicolasHoizey : pas faux, mais cela complexifie l’ajout de nouveaux objets. Antoine : ajouter de nouveaux objets ne fait pas vraiment partie des objectifs... et du reste, cela signifie créer deux tables au lieu d’une seule, rien de bien compliqué.)& ;amp;lt ;/quote& ;amp;gt ;
bill : un point important à mon avis est de pouvoir indexer ces champs et y elargir(optionnellement ?) la recherche. une question : à force d’ameliorer les extra est-ce qu’on ne peut pas envisager une structure qui gere à la fois les champs extra et les mots clé ? (enfin l’equivalent d’une utilisation simple, sans les groupes, vu que c’est la dessus que doit à mon avis se decider l’approche mots cle / extra Action inconnue "Minh : pas d’accord, la différence c’est que les mots clés prennent leur valeur dans un vocabulaire contrôlé, alors que les champs extra ont des valeurs chaines libres", et que c’est sur la gestion des groupes qu’il y a des ameliorations à apporter) Il y a du bon dans les deux, et cette approche rendrait envisageable les recherches sur les extras (à reflechir car bonjour la taille cache). Sinon la structure proposée a l’air bien riche, il ne manque plus que les droits d’accès, mais la colonne condition devrait suffire.
D’autres aspects des champs extra sont liés à l’InterfaceDeLEspacePrive.
Questions JLuc : et dans la lancée, est-ce que les types mêmes des objets (ARTICLES, BREVES, etc) pourraient pas être paramétrés intialement dans une table SPIP_TRAME modifiable, et donc, pour certains, effaçables, ou pour d’autres non encore existants, créatables ? ( avec comme champs de SPIP_TRAME : & ;amp;lt ;code& ;amp;gt ;nom_objet& ;amp;lt ;/code& ;amp;gt ; (ARTICLES, BREVES, AUTEURS, FORUMS, ...) & ;amp;lt ;code& ;amp;gt ; effaçableouinon& ;amp;lt ;/code& ;amp;gt ; (non, oui, non, oui, ...) & ;amp;lt ;code& ;amp;gt ; nom_table& ;amp;lt ;/code& ;amp;gt ; (pas franchement nécessaire si on garde la convention de nommage SPIP_nomtype ) )
esj : Pour ma part, j’ai proposé sur [Spip-contrib-& ;amp;gt ; http://www.spip-contrib.net/ecrire/articles.php3 ?id_article=483] un traducteur de squelettes qui permet d’appliquer une balise BOUCLE à n’importe quelle table SQL. Il me semble que c’est la solution la plus générale, car Spip devient ainsi un moteur paramétrable de mise en pages pour n’importe quelle BD SQL. N’est-ce pas ce que tout le monde réclame ici sans le dire explicitement ?
— (Antoine) Pas exactement, il s’agit ici d’avoir une généricité qui reste liée à SPIP, avec une interface dans l’espace privé pour ajouter des champs aux objets existants (articles, brèves, etc.). La possibilité d’utiliser le moteur pour n’importe quelle table SQL pourra peut-être venir en bonus, mais ça ne fait pas partie des objectifs de départ.
— Minh : Le nouveau compilateur évoqué ci-dessus a été intégré à la branche principale de SPIP. Sa documentation est [par là-& ;amp;gt ;http://www.spip-contrib.net/spikini/NouveauCompilo]. Voir aussi la discussion des champs extra sur le [spikini-& ;amp;gt ;http://www.spip-contrib.net/spikini/ToDoChampsExtra]