sur la question des champs extra, je trouve ça, pour le moment,
encore compliqué
Ces champs doivent être considéré comme obsolètes depuis que le
compilateur de la 1.8.
On y reviens. Et c'est là que je trouve qu'il y a eu un soucis de comm'.
Mais j'aurais peut-être du dire 'bug de la doc' ?
Il a si j'ai bonne mémoire toujours été dit que ces champs Extra étaient des tentatives non stabilisées d'extension des champs de base, mais que tant qu'aucune alternative fiable serait développée, ils resteraient opérationnels.
Ce n'est pas ce que je qualifierais d'« obsolète », puisqu'il n'y a dans les faits pas d'alternative fiable offrant la même intégration de nouveaux champs dans les formulaires de saisie des contenus.
Il y a bien la lecture dans des tables externes et le plugin Forms&Tables qui apportent d'autres solutions très utiles, mais elles ne peuvent selon moi pas encore totalement remplacer les extras.
Je suis du CNRS mais ne connais personne qui travaille à l'UREC. D'après ce
que j'en ai reçu, le projet PLUME a pour but de produire des fiches techniques
pour présenter des logiciels libres utilisables par les labos. Un peu comme
Framasoft ou Freshmeat, mais spécialisé et avec sélection sévère.
L'étude citée ne préjuge donc pas des recommandations de PLUME pour les labos.
Je constate en fait que pour l'instant seul SPIP est recommandé dans la
catégorie "CMS": http://www.urec.cnrs.fr/rubrique256.html . C'est Joël Courant
qui a rédigé la fiche SPIP http://www.urec.cnrs.fr/IMG/pdf/LL.fiche_SPIP.pdf .
Je suis certain que si d'aucuns dans la communauté prend le temps de suggérer
des améliorations et des mises à jour à la fiche, il les lira avec intérêt.
Dans le même genre si quelqu'un a le temps de faire la fiche SPIP pour
QSOS. Je m'étais proposé pendant les RMLLs, mais je doute d'en avoir le
temps ....
Hop, je prends connaissance des messages au retour de mes vacances...
De la part de Committo,Ergo:sum
Envoyé : lundi 23 juillet 2007 22:59
Si plusieurs tables Statut_X contiennent
un certain id_article, on prend le plus récent, car ce
qu'offre en plus cette architecture c'est d'avoir un
historique des statuts successifs, ce qui va dans le sens
d'un "workflow" redéfinissable.
Tilt ! Si tu ajoute un champ date, tu peux programmer une série d'états
successifs, comme la date de publication antérieure. Et à ce prix là, un
mécanisme 'cyclique' serait intéressant aussi (par exemple des articles qui
ne seraient publiés que le lundi, le mardi, etc..).
