Ce jeudi 5 septembre à 22h52, Fil a répondu:
@ Anne Possoz <anne.possoz@epfl.ch> :
> Donc un champ supplémentaire serait la solution propre, de mon
> point de vue.Si on te suit, spip_rubriques passe de 3 champs texte (titre, texte,
descriptif) à 4 champs. Qu'est-ce que ça a de plus propre ? Si tu utilises
un des trois champs pour l'ordre, il t'en reste deux... Donc, en bonne
logique, ce que tu souhaites c'est avoir 4 champs texte au lieu de 3. Ca
n'est pas exactement la même question que celle que tu soulèves.
Je croyais pourtant avoir demandé cela: "un champ supplémentaire".
Les 3 champs texte ne devraient pas contenir des informations que
l'on n'y met que pour contourner l'obstacle que aucun champ n'est
disponible pour des tris. Si je propose un champ texte, c'est bien
parce que d'autres pourraient vouloir en faire autre chose.
Pour les articles, c'est un peu moins critique car on a déjà
beaucoup de champ. Je pourrais facilement utiliser surtitre ou ...
> En lisant les questions, on voit que ce champ pourrait servir
> à d'autres pour d'autres solutions. C'est dans ce sens que je
> pense à un champ "critère" qui serait plus général.Peut-être que d'autres voudraient 5 ou 6 champs, d'autres encore 10... (ça a
été demandé pour les spip_articles). Où placer les limites ?
Je réalise cela. Mais les entourloupettes à faire me semblent
néfastes pour l'avenir de sites construits sous spip.
Ou alors, pourrait-on imaginer que spip permette l'addition de champ
sans tout casser. Je me rends compte... ce ne serait plus une uzine à
spip mais une usine à gaz.
Avons-nous un endroit où il est possible de rassembler les demandes
de champs supplémentaires? Je serais intéressée. On pourrait débattre...
> En plus, je ne vois pas quelle partie du code fait cette trans-
> formation "!" --> " !"la fonction propre() (ecrire/inc_texte)
Merci.
Donc je viens de trouver comment patcher pour que les commentaires
dans les textes ne soient plus cassés par spip (voir patch en annexe
mais je ne sais pas sous quelle forme faire un patch, pardon
J'ai fait un "diff -bu ancien nouveau").
Cela permet d'ordonner des rubriques (des articles sûrement aussi
mais je n'y suis pas encore) en ajoutant au début d'un des champs
(on peut choisir mais c'est sur lui qu'on fera le tri) une occurence
<!--ii--> pour ordonner ses rubriques ou ses articles.
Cela ne résoud pas le problème de la base de données qui est ainsi
encrassée. De plus, on ne voit ces informations qu'au moment de l'édition
de la rubrique ou de l'article.
Cela ne résoud pas non plus le problème de l'exportation propre
de la base de donnée pour du xml ou autre. Mais cela donne le
temps de réfléchir à la solution la plus propre.
% % % %
Bref, l'histoire des numéros n'est pas satisfaisante, mais l'ajout d'un
champ n'est pas vraiment la solution.
Pourquoi? Un champ qui paraît si évident dans une base de donnée.
Dire que je n'en suis encore qu'au squelette de mon sommaire.
Merci pour la discussion.
Anne
ecrire.inc_texte.php3.diff (665 Bytes)
