Idée:
- Un liste-skels.html qui irait chercher les squelettes disponibles dans le path de spip avec les itérateurs.
- Dans ce fichier une explication sur le "pourquoi squelettes-dist est désormais vide et pourquoi personnaliser dans "squelettes".
- Dedans aussi un bouton (calqué sur la fonctionnalité de skeleditor) qui permet de recopier le squelette pointé vers squelettes
- On place ce fichier dans squelettes-dist (comme ça ceux qui cherchent ce dir le trouvent)
Mes 2 sous
Le 02/03/2012 12:39, Suske disait :
- Dans ce fichier une explication sur le "pourquoi squelettes-dist est
désormais vide et pourquoi personnaliser dans "squelettes".
Oh oui oh oui. 
Et les formulaires ne font pas partis d’un squelette au sens « tout cohérent » : ils peuvent être évidemment surchargés ponctuellement si vraiment on veut changer un truc, mais par défaut les formulaires doivent pouvoir être utilisés n’importe où : dans la dist ou autre part. Donc il ne font pas partis de la dist.
si je résume : les formulaires sont rangés dans « squelettes » car ce ne sont pas des squelettes.
Alors que les squelettes, qui sont des squelettes, sont rangés hors de « squelettes ».
vous trouvez ça normal docteur ?
– Fil
Ben c'est ce que j'ai dit à Cédric l'autre jour sur IRC.
À la limite faudrait renommer ce dossier, qui fournit bien des éléments à utiliser en partie publique mais ce ne sont pas des squelettes.
Cédric disait que ça n'avait rien à faire dans prive/ donc on ne peut pas les déplacer là. Mais ça n'a rien à faire dans un truc qui s'appelle "squelettes" non plus.
Donc je crois que si on renomme ce dossier en enlevant ce terme qui embrouille tout le monde, alors on peut sortir SPIP 3 !
Si c'est juste un nom de dossier à changer, ça va. 
Le 02/03/2012 13:56, RastaPopoulos disait :
À la limite faudrait renommer ce dossier, qui fournit bien des éléments
à utiliser en partie publique mais ce ne sont pas des squelettes.
Tant qu'à faire, et partant du fait qu'ils sont tout aussi surchargeables que le reste, pourquoi ne pas tout mettre dans extensions/dist/ directement ?
(ou alors il y a encore un truc que je ne comprends pas ?)
si je résume : les formulaires sont rangés dans "squelettes" car ce ne
sont pas des squelettes.
Alors que les squelettes, qui sont des squelettes, sont rangés hors de
"squelettes".vous trouvez ça normal docteur ?
Ben c'est ce que j'ai dit à Cédric l'autre jour sur IRC.
À la limite faudrait renommer ce dossier, qui fournit bien des éléments à utiliser en partie publique mais ce ne sont pas des squelettes.
/perso ?
Cédric disait que ça n'avait rien à faire dans prive/ donc on ne peut pas les déplacer là. Mais ça n'a rien à faire dans un truc qui s'appelle "squelettes" non plus.
Je rappelle que cela a déjà été discuté avec d'autres par là :
http://comments.gmane.org/gmane.comp.web.spip.devel/61762
et résumé dans ce ticket :
http://core.spip.org/issues/2501
Donc je crois que si on renomme ce dossier en enlevant ce terme qui embrouille tout le monde, alors on peut sortir SPIP 3 !
Si c'est juste un nom de dossier à changer, ça va.
Go go go
-- Romy
Tant qu’à faire, et partant du fait qu’ils sont tout aussi surchargeables que le reste, pourquoi ne pas tout mettre dans extensions/dist/ directement ?
Ca reviendrait à renommer squelettes-dist/ en extension/dist/ ; juste pour le plaisir de changer des trucs ?
Techniquement, c’est kif kif, mais en termes de compréhension et de doc, il me semble important d’avoir de bons nommages (nomenclatures, etc.).
– Fil
il y a très très longtemps, bien avant spip 1.8, de mémoire, on a
choisi ce nom parce que la seule personnalisation possible était les
squelettes (et les filtres à placer dans mes_fonctions.php).
à l'époque où on a crée config/ tmp/ local/, on avait envisagé de
changer son nom. On avait pensé à perso/ mais aussi home/ voire var/
enfin, vous voyez le genre....
Même que config/ s'appelait etc/ au tout début, c'est vous dire 
Non techniquement ce n'est pas kif kif, car là il s'agit des formulaires fournis par le noyau et utilisable alors aussi par *d'autres* squelettes que la dist.
Donc justement il ne faut *surtout pas* que ces formulaires se retrouvent dans la "dist", puisque le but c'est de pouvoir, par exemple, supprimer la dist est mettre un autre squelette par défaut pour une autre distribution.
Attention, je ne parlais pas du nom du dossier utilisable par les gens pour mettre leurs surcharges et personnalisations (et là je trouve que perso/ c'est pas mal oui).
Mais je parlais du dossier qui contient actuellement les restes de "trucs utilisables en public et fournis par le noyau mais qui ne sont pas des squelettes", càd essentiellement des formulaires, et qui sont pour l'instant dans le dossier "squelettes-dist".
Il faudrait donc renommer "squelettes-dist" en autre chose, puisque ça ne contient plus de squelettes. Et alors il n'y aura plus vraiment de confusion sur où se trouve les choses car on ne ferait pas croire qu'il y a des squelettes dans ce dossier.
/core ?
/core-fonctions ?
/core-etendu ? (non j'déconne...)
/core-noisettes
...
/commun
/tronc-commun
/partage
/utile
/briques
...
bien, je comprends aussi : j'essaie de mettre ça à plat dans la page doc
SPIP3 du carnet...
Super démarche, BRAVO et merci !
Enfin un peu de doc. rémanente
pour avoir une vue de compréhension
=> je suggérerais bien d'avoir dans Contrib
assez systématiquement un lien possible
vers un article du carnet :
-> cela facilite le suivi évolutif
par tous les intéressés
-> et il suffirait d'en faire l'intégration (modèle)
en tant que modèle pour garder un fonctionnement
ouvert en forum-discussion.
En ces temps de grands changements, le besoin
de documenter serait beaucoup plus ouvert et collaboratif
Qu'en pensez-vous ?
YannX
Je rate sans doute des discussions, ayant été absent de cette liste
Je rate totalement la compréhension, mais je beta-teste des nouveaux :
Avant la doc disait à peu près :
"Les squelettes par défaut sont dans le répertoire squelettes-dist/"Maintenant la doc devra dire :
"Les squelettes par défaut sont dans le répertoire extensions/dist/"Si la doc est à jour, il n'y a pas de problème pour que les nouveaux,
ceux qui ne connaissent pas, trouvent l'information, non ?
Quand on voit sur les listes, le nombre de "vieux" sites restants,
parfois repris par des débutants, je me dis que ce n'est pas
forcement aussi simple : peut-etre sera-t-il plus clair
de garder *deux* versions d'articles de certaines docs
(avec les liens de passage croisé entre SPIP2 et SPIP3).
(Et Romy de répondre : oui mais c'est tellement le bazar que même moi
qui bosse sur la dist j'arriverai pas à écrire la bonne doc.)Alors c'est quoi qui est le bazar ?
Car tous les *squelettes* sont dans extensions/dist. Les squelettes hein
: les fichiers qui disent "je mets telle info à telle endroit". Ce qui
ne comprend pas les *formulaires* qui eux sont des éléments
fonctionnels, d'action, fournit par le noyau.
J'ai trouvé *génialement simple* cette définition,
comparativement aux thèmes :
merci pour la formulation limpide !
Bonjour,
Je fais "rétro" mais l'idée de virer "squelettes" pour le remplacer par "perso" ne paraît présenter d'avantage significatif en terme de clarté, surtout pour les habitués à utiliser "squelettes", ...ce qui représente une bonne partie des utilisateurs.
De ce que je retiens de vos échanges, il apparaît que la "mutation" des répertoires soit loin d'être achevée, alors que le début d'analyse des fonctions de destination est très intéressant.
Je vais donc y rajouter une couche.
Car pour moi Zpip et ses thèmes, un peu comme ce qui se passe actuellement avec "extensions" ça désigne plutôt des "toolkits".
Et ça me conduit à suggérer à terme une répartition comme ceci (je donne ça par exemples de chemins dans l'arborescence):
- toolkits/zpip/zpip-core
- toolkits/zpip/themes
- toolkits/default/squelettes
- toolkits/default/plugins
- toolkits/default/formulaires
- toolkits/default/modeles
- plugins/auto
- custom/squelettes
- custom/perso
...mais bon en gros "squelettes" c'est un peu affectif l'idée de le garder quand-même, mais franchement /perso me parait d'autant moins clair qu'appliqué à un projet collaboratif le mot me semble presque gossier
@+
Philippe
Bonsoir, Bxl
2012/3/2 chankalan <chankalan@free.fr <mailto:chankalan@free.fr>>
je comprends le raisonnement, mais alors pourquoi sont-ils dans
/squelettes-dist/ ?Idée:
- Un liste-skels.html qui irait chercher les squelettes disponibles dans
le path de spip avec les itérateurs.
Cela rejoint une discussion IRC
de l'an passé avec JLuc ;
mais je ne vois pas de solution "SPIP" !
Si tu as une idée pour programmer cela
(voire une dérivation d'un include_spip.php ?? )
tu m'interesse bcp !
Et j'ajouterai que tes pistes d'extensions
à skeleditor (et switcher/theme) me semblent
utiles pour résoudre les soucis de "nouveaux"
@SPIP3 
- Dans ce fichier une explication sur le "pourquoi squelettes-dist est
désormais vide et pourquoi personnaliser dans "squelettes".
- Dedans aussi un bouton (calqué sur la fonctionnalité de skeleditor)
qui permet de recopier le squelette pointé vers squelettes
- On place ce fichier dans squelettes-dist (comme ça ceux qui cherchent
ce dir le trouvent)
Dans le meme ordre d'idée, ou pourrait-on proposer
un analyseur d'arborescence CSS ?
Mes 2 sous
--
Suske
Cdlt
YannX
Le 02/03/2012 19:06, YannX disait :
Si la doc est à jour, il n'y a pas de problème pour que les nouveaux,
ceux qui ne connaissent pas, trouvent l'information, non ?Quand on voit sur les listes, le nombre de "vieux" sites restants,
parfois repris par des débutants, je me dis que ce n'est pas
forcement aussi simple : peut-etre sera-t-il plus clair
de garder *deux* versions d'articles de certaines docs
(avec les liens de passage croisé entre SPIP2 et SPIP3).
Oui, très vrai.
Les gens qui s'occupent de la doc de spip.net (ou ailleurs), que penseriez-vous de prendre toute la doc et de la mettre dans une rubrique fr/spip2/ et de dupliquer/réécrire dans fr/spip3/ ?
Pourquoi ne pas utiliser un mot clé pour chaque version et afficher l'arborescence en conséquence? (un peu comme sur contrib même si ça ne sert pas à la navigation)
Cela permettrait de ne pas dupliquer le contenu et doubler la maintenance des articles...
Bonjour,
Il y avait déjà (entre autre) eu un fil de discussion sous un article de
romy sur http://www.spip-blog.net/Typologie-des-utilisateurs-pour-
reconquete.html
Rastapopoulos a travaillé sur un réaménagement de spip.net sur le carnet
de contrib http://www.spip-contrib.net/Refonte-de-spip-net
Pour ma part, j'ai relié ces deux sources en réfléchissant à une refonte
qui permette une campagne collaborative d'écriture de la documentation et
j'en suis pour le moment arrivé à ceci : http://www.spip-contrib.net/
Proposition-de-refonte-de-spip-net
A noter ce plugin http://www.spip-contrib.net/Nouvelle-version-Moderation-
de-modifications qui dans le cadre d'une gestion de documentation permet
à toute personne avec un simple statut redacteur de proposer une nouvelle
version d'un article de manière claire et efficace.
Amicalement
Stanislas
Dommage de refaire un deuxième article sur le même sujet + avec le même titre quasiment, au lieu d'essayer d'avancer à partir d'une même base.
Je rappelle que le but n'est pas de repartir à zéro, ça me parait difficilement faisable, surtout qu'il n'y a pas qu'une langue à reprendre mais il faut prendre en compte les dizaines de langues déjà existantes et le fait qu'il n'y a pas le même contenu dans chaque.
Bref : faire avec l'existant avant tout.
Ma proposition cherchais donc à tout réorganiser, certes, mais en se basant sur les articles existants afin d'avoir à faire le plus possible des déplacements, plutôt que des créations ex-nihilo.
Mais bon, tout ceci n'a rien à faire dans ce fil de discussion.
Pour ma part, j'ai relié ces deux sources en réfléchissant à une
refonte qui permette une campagne collaborative d'écriture de la
documentation et j'en suis pour le moment arrivé à ceci
:http://www.spip-contrib.net/ Proposition-de-refonte-de-spip-netDommage de refaire un deuxième article sur le même sujet + avec le même
titre quasiment, au lieu d'essayer d'avancer à partir d'une même base.
Je rappelle que le but n'est pas de repartir à zéro, ça me parait
difficilement faisable, surtout qu'il n'y a pas qu'une langue à
reprendre mais il faut prendre en compte les dizaines de langues déjà
existantes et le fait qu'il n'y a pas le même contenu dans chaque.
Bref : faire avec l'existant avant tout.
Ma proposition cherchais donc à tout réorganiser, certes, mais en se
basant sur les articles existants afin d'avoir à faire le plus possible
des déplacements, plutôt que des créations ex-nihilo.
Sauf que, dis moi si je me trompe, en attaquant le problème avec juste
une réorganisation de la doc : c'est compliqué...
En lisant et relisant les fils de discussion, je me suis demandé si on
attaquait pas la montagne par un voie trop escarpée...
Car, en fait, il y a bien deux principes qui semblent a priori
inconciliables dans ces échanges :
- faire avec l'existant
- et repartir sur de nouvelles bases.
En somme : on ne veut pas partir d'une page blanche, mais en même temps,
on aimerait bien tourner la page !
Et chaque version majeure de spip relance le débat...
J'en suis venu à me dire qu'il ne fallait pas un chantier (ponctuel) de
refonte de la doc mais une démarche permanente de refonte de la doc...
D'où l'idée que chaque nouvelle version majeure enclenche un archivage de
la doc et la mise en place d'une nouvelle version, même si on reprend
tout ou partie des textes existants. Cela existe ailleurs, par exemple,
un bouquin de doc sur ubuntu ressort remanié à chaque version. Mais le
hic, c'est que c'est le travail d'un auteur principal. Or il faudrait
avoir une méthodologie qui permette à tout spipeur d'apporter une
contribution. C'est une demande récurrente aussi : avoir le moyen de
pouvoir faire un retour à la communauté même tout petit petit...
D'où l'idée de structurer le plus possible : une ligne éditoriale
générale, une ligne éditoriale par rubrique, et une seule question
traitée par article.
Cette idée reste à être éprouvée en la confrontant à la réalité (d'où ma
page à part sur le carnet...) mais si ça se tient, on aura un listing des
questions à traiter établi par les admin de spip.net (qui pourra faire
l'objet de suggestion de tout spipeur) et chaque question pourra être
traitée par qui veut s'y coller en respectant une ligne éditoriale et des
consignes pour que cela ne parte pas en vrille.
Les articles qui n'évoluent pas entre deux versions, sont simplement
repris. La différence avec la situation d'aujourd'hui est qu'ils
recevront une revalidation explicite (nouvelle date) ce qui est une
indication claire pour le nouvel utilisateur qui s'intéresse uniquement à
la version de spip qu'il vient de télécharger ; et que l'opération donne
la possibilité de remanier un texte sans changer le fond mais simplement
pour qu'il soit plus clair ou ajouter un lien ou un exemple...
Mais bon, tout ceci n'a rien à faire dans ce fil de discussion.
Faut voir. SPIP 3 a besoin de sa doc pour sortir... L'idée qui a été
lancée d'organiser une campagne d'écriture de la doc serait peut être un
projet stimulant pour les spipeurs et un buzz intéressant pour l'arrivée
de la version... même pour les articles en langues étrangères qui parfois
datent aussi...
Stanislas