Bonsoir,
Un mot pour savoir si une documentation ou une ébauche de documentation
est déjà disponible quelque part pour le "champ extra".
Merci
FS
PS : Pour la journée SPIP pendant le FSE, je suis sans doute intéressé.
Un mot pour savoir si une documentation ou une ébauche de documentation
est déjà disponible quelque part pour le "champ extra".
Oui! Voir:
http://www.spipquebec.org/article.php3?id_article=24
http://www.spipquebec.org/article.php3?id_article=28
Pas une documentation officielle, mais certainement une bonne description de
la chose avec des conseils pour utilisation dans les squelettes.
André Vincent
Bonjour,
Voici quelques éléments de réflexion sur l'avenir de SPIP que m'inspire
la lecture de inc_extra. Peut-être que je délire complètement; mais ça
me gratte trop que pour ne pas en parler.
Pour en venir au problème, j'ai l'impression que l'utilisation des
"rubriques" à plusieurs fins différentes mène dans une impasse, ou à
tout le moins à un gros conflit.
La "rubrique" sert en effet aujourd'hui à définir plusieurs choses :
- Le contenu, le classement thématique, selon la logique de
l'arborescence. Un site web présente des rubriques, puis des
sous-rubriques,... etc. Tous les visiteurs comprennent (voire ont besoin
de ce repère commun pour naviguer dans le site). Beaucoup de sites
utilisent les rubriques de SPIP à cette seule et unique fin.
- Avec inc_extra, la rubrique définit maintenant la NATURE d'un élément
(implicitement puisque c'est via les rubriques qu'il devient possible de
modifier spécifiquement la structure des articles/brèves,...). Donner
cette possibilité aux utilisateurs est capital puisque cela permet de
franchir un pas important vers une universalisation de l'outil : les
utilisateurs ne sont plus soumis à la typologie initiale des données
mais peuvent la définir eux-mêmes (Considérer qu'un site web est composé
d'articles, de brèves, de liens,... ; que ceux-ci sont composés de tels
et tels champs est en effet déjà en soi un engagement axiologique fort).
- En plus de cela, les rubriques servent maintenant à caractériser la
langue (si j'ai bien compris, il est recommandé de créer un secteur pour
chaque langue utilisée dans un site) et à beaucoup d'autres aspects
utilitaires (l'utilisation de "rubriques techniques", non visibles du
public, s'impose dès qu'on atteint un certain niveau d'utilisation du
logiciel).
Autrement dit, pour n'en rester qu'au conflit induit par les deux
premiers usages, on est obligé de choisir entre une utilisation des
rubriques comme structure logique du site (arboresence) ou comme
typologie des éléments. Les deux sont très peu compatibles. Si on
souhaite spécifier des éléments particuliers requérant une config sous
inc_extra, on est obligé de créer une rubrique pour chacun d'entre eux.
Il n'est alors plus possible de classer ces éléments dans une
arboresence.
Je pense donc qu'il faudrait réfléchir à la possibilité d'implémenter
une typologie ouverte des éléments de SPIP (ce qui impliquerait de
rajouter une couche d'abstraction à ce qui existe mais aussi
d'"objectiver" tous les éléments de SPIP). Je vais essayer de faire une
proposition eu peu plus construite d'ici quelques jours (intégrant un
mode de gestion des données).
FS
PS: Que tout ceci ne m'empêche pas de souligner la qualité du code de
inc_extra et son caractère hautement nécessaire.
La "rubrique" sert en effet aujourd'hui à définir plusieurs choses :
Tu as raison de souligner ce risque ; toutefois il faut bien avoir à
l'esprit que faire de l'extra, du multilinguisme et du thématique dans le
même site pose *obligatoirement* des problèmes, indépendamment du fait qu'on
peut s'appuyer sur les rubriques pour ces trois éléments.
Pour ce qui est du thématique, les mots-clés peuvent remplacer les
rubriques, si besoin.
Pour ce qui est du multilinguisme, il *peut* se gérer au niveau des articles
(et pas par rubrique ou par secteur : c'est juste une commodité pour aller
au plus vite).
Enfin, les extras ne sont pas là pour définir la nature des articles, mais
juste pour les étendre *un peu*, histoire de *contourner* les limitations
(volontaires) de SPIP. Si tu as besoin des les étendre beaucoup et de faire
un système où ils diffèrent énormément d'une rubrique à l'autre, SPIP n'est,
à mon avis, pas le bon outil (regarde plutôt du côté de Zope...).
(l'utilisation de "rubriques techniques", non visibles du
public, s'impose dès qu'on atteint un certain niveau d'utilisation du
logiciel).
Cet aspect là, en tout état de cause, ne figure pas dans SPIP : nous avons
refusé d'ailleurs une modification "du noyau" qui aurait permis d'avoir des
rubriques cachées ... et je crois qu'une des conséquences (indirectes) du
multilinguisme sera de pouvoir se passer de ce type de bidouillages.
PS: Que tout ceci ne m'empêche pas de souligner la qualité du code de
inc_extra et son caractère hautement nécessaire.
Ce code est assez ouvert, et facile à étendre : pour l'instant il se base
sur l'id_rubrique, ça n'est là encore qu'une proposition (j'aurais pour ma
part préféré que les extras soient les mêmes partout sur le site).
-- Fil
langue
Tu aurais pu mentionner que la rubrique ou le secteur sert aussi :
- pour sectoriser les brèves
et surtout :
- pour les droits d'accés en modification etc via les admins restreints
Toutes fonctions - plus ou moins - indépendantes,
pour un même support.
Souvenir... : L'implémentation initiale des #EXTRA avait l'avantage
de ne pas coller ainsi aux rubriques.
JLuc
Formidable ! J'ouvre ma boîte mail avec la ferme intention de demander
où se trouve cette fonctionnalité que je n'avais pas trouvé dans la
1.7a8 et voilà une doc qui arrive toute faite 
Merci à l'équipe de Spip pour cette fonctionnalité et merci à toi pour
la doc !