Dans cette version, il y a des nouveautés nouvelles (:)). Et il y a aussi des nouveautés qui remplacent d'anciennes méthodes.
Peut-on considérer comme à oublier, les documentations des fonctions obsolètes, qui 1) ont déjà été documentées dans la version précédente du site, et 2) ont une nouvelle méthode recommandée pour faire la même chose ?
Le but est d'alléger la documentation en n'y laissant que ce qui est valide ET recommandé. Pour ne pas avoir 3 manières différentes de faire la même chose alors qu'une seule des 3 sera pérenne.
IL y a déjà plusieurs exemples concrets :
- dans l'ancienne version il y avait déjà deux méthodes différentes pour faire les pages du privé. Désormais avec Z, ça porte à 3 manières, alors qu'une seule devrait être la voie à suivre : donc le choix serait de virer les deux anciens articles et ne décrire que la manière avec Z.
- même principe avec plusieurs fonctions "declarer_tables_TRUCS" qui fonctionnent toujours mais qui sont gardées pour compat ascendante, et non pas pour en faire la promotion : il faudrait donc peut-être les enlever aussi et ne documenter que le nouveau gros pipeline "declarer_tables_objets_sql"
Sachant que dans tous les cas, la doc de la branche 2 restera en ligne sur un autre domaine, et que donc on ne perd rien de ce qui est déjà documenté.
Oui, l'idée que j'avais de Programmer, c'est qu'il ne traine pas les méthodes dépréciées, mais qu'il soit à jour des règles de l'art, sans dire «depuis SPIP 2.1» ou «À partir de SPIP 3 ça se passe comme ça»
Donc, pour les pages privées, je serai d'avis de ne conserver que la manière Z.
Pour les declarer_tables_TRUCS, c'est plus compliqué, car la déclaration globale d'un objet ne s'applique que pour des objets éditoriaux (dixit cédric), (pas les statistiques par exemple) qu'on peut éditer depuis le privé. Or, toute table n'est pas forcément un objet éditorial, ce qui fait que la recommandation semble de dire que il faut utiliser le pipeline objet_sql pour un objet, sinon les autres.
Enfin, on peut imaginer pourquoi pas un chapitre «migration 2.1 -> 3.0» qui explique les changements, mais pas à même les articles de référence, dans un chapitre à part s'il le faut donc.
+1. C'est ce qui a figé et rendu peu lisible la doc de spip.net
Je n'ai jamais compris pourquoi on ne pouvait pas archiver la doc comme
les zip de spip...
J'avais pu modestement suggéré il y a longtemps qu'au moins LE texte de
newbie en spip soit débarrassé de ses php3 : http://www.spip.net/
fr_article879.html mais non, spip.net ressemble de plus en plus à un
mausolée, un témoignage de l'ancienne spipitude, que l'on a tous aimé et
qu'on aime encore, mais bon...
Moi j'aime bien comment est écrit spip.net.
Ça permet de n'avoir qu'une doc, quelle que soit la version qu'on a.
Ça permet de toujours trouver où on est, et ce qu'on doit appliquer.
Ça permet de voir "pourquoi c'est un truc dans un spip d'une assoc et pas pareil avec une autre, et pourtant c'est spip partout ?" (entendu x fois).
Et ça permet de voir que SPIP est vivant, qu'il évolue et que c'est pas du tout un machin figé ou qui change sur un coup de tête, mais avec réflexion et avancement.
Si, si, j'aime bien ce côté dans SPIP.net, qu'il me semble indispensable de garder.
En revanche, évidemment, c'est la manière de l'aborder, de le lire, de trouver (ou plutôt de ne pas trouver) les infos qui est toujours bancale dans spip.net.
Mais ça n'a rien à voir avec la mémoire de SPIP qu'il inclut et qui est primordiale.
Selon moi bien entendu.
Le Dimanche 29 Mai 2011 12:47:20 Stanislas <stanislas76@free.fr>, dans un message intitulé "Re: [spip-dev] Doc SPIP 3 et méthodes dépréciées" nous a informés :
Moi j'aime bien comment est écrit spip.net. Ça permet de n'avoir qu'une
doc, quelle que soit la version qu'on a. Ça permet de toujours trouver
où on est, et ce qu'on doit appliquer. Ça permet de voir "pourquoi c'est
un truc dans un spip d'une assoc et pas pareil avec une autre, et
pourtant c'est spip partout ?" (entendu x fois).
Et ça permet de voir que SPIP est vivant, qu'il évolue et que c'est pas
du tout un machin figé ou qui change sur un coup de tête, mais avec
réflexion et avancement.
Si, si, j'aime bien ce côté dans SPIP.net, qu'il me semble indispensable
de garder.
Oui, tu as raison, lorsque l'on découvre un nouvel outil, on est rarement
impatient de trouver la bonne info pour arriver directement au résultat
souhaité.
Lorsque l'on passe sur des passages inutiles qui rallonge la doc et font
perdre un peu de temps... sur des passages morts donc... on est
immédiatement saisi par le côté vivant de la chose... on mesure sa chance
de pouvoir communier avec l'esprit vivant et réfléchi d'une communauté...
En revanche, évidemment, c'est la manière de l'aborder, de le lire, de
trouver (ou plutôt de ne pas trouver) les infos qui est toujours bancale
dans spip.net. Mais ça n'a rien à voir avec la mémoire de SPIP qu'il
inclut et qui est primordiale.
Bien sûr, et le côté "bancale" n'a aucun rapport avec le côté "strate
géologique", car enfin, la mémoire de SPIP, la vraie, la pure, ne serait
s'organiser, elle se doit d'être sédimentée...
Selon moi bien entendu.
Bien entendu, en vérité je vous le dis, qui renie le php3 n'est pas
SPIP...