[spip-dev] réflexions sur le nommage dist, squelettes-dist, etc.

Dev
1

Entre les différents fils qui changent de sujet, je retrouve plus le
bon, d'ailleurs je suis pas sûr qu'il y en ait un dédié au sujet, alors
c'est l'esprit embué que je commence celui-ci, hop.

À un moment, y'a longtemps, je crois qu'on s'était dit que SPIP était
désormais utilisé pour divers profils de sites, et que pour suivre
cette réalité on voulait sortir du modèle de "Dist" unique au profit de
distributions multiples. Par distribution on entend un jeu de
squelettes et de plugins, formant un tout cohérent, et que le public
visé para la distribution en question (à chaque public sa distribution,
donc) puisse utiliser directement.

Du coup, bon, j'ai loupé le moment où il a été décidé de faire une
extension qui s'appelle "dist", mais laissez-moi vous dire que c'est un
nom aussi informatif que le plus chiant des journaux de TF1. Quel
public est visé ? Alors du coup, effectivement, si on va faire une
extension "dist", je comprends la confusion de certaines personnes entre
"squelettes-dist" et "extensions/dist"... Le second n'apporte rien au
premier, car on reste sur le modèle d'un seul standard, donc à ce
compte-là c'est comme tout laisser dans squelettes-dist...

Pour rappel: il y a genre 1 an (plus ?), j'avais commencé à sortir des
bouts de squelettes-dist dans extensions/dist2007 (on avait discuté
entre quelques personnes de plusieurs noms possibles, personne avait
rien trouvé de probant), qui était l'état de l'art de la dist unique
de l'époque. Il y a eu quelques allers-retours entre squelettes-dist et
extensions/dist2007, mais au final on a trouvé un équilibre où le
répertoire squelettes-dist continuait à fournir les quelques bouts du
core qui utilisés dans le public, et surchargeables, et dist2007
l'espèce de thème mauve chelou là, ouvert au changement (oh oui oh
oui).

Bon, en un mot comme en cent, je voulais juste qu'on perde pas de vue
que si y'a actuellement un dossier "extensions/dist", c'est juste le
fait d'un piètre choix de nommage, et que ce fruit du travail
artistique des devs (ça veut bien dire ce que ça veut dire !) est le
premier d'un futur riche éventail de distributions adaptées à tous les
sites de la planète (en attendant d'en coloniser d'autres). Du coup je
propose qu'on réfléchise à un nom un peu plus funky et descriptif,
comme ça on arrêtera de dire qu'il faut tout remettre dans
squelettes-dist, et ça donnera un peu de chien à l'écureuil.

Après 10 bonnes secondes de réflexion, je propose "rouge-mini", en
espérant ne vexer personne.

Bien sûr, on pourrait croire que ça n'apporte rien à la question du
renommage de squelettes-dist, mais en vrai si.

2

Bonjour,

A chaud, et n'ayant pas suivi toutes les discussions...

un "Squelette" pour moi est ce qui tient, structure un "être", mais ce n'est pas l'être lui-même.
Et les "quelques bouts de core" dans "squelettes/dist" correspondent bien au concept de squelette.

Ensuite, en quoi consiste "l'être" tenu par le squelette ?
En un service fourni par le site, service informatique, services que l'on nomme sur d'autres supports "Application".
Le mot "Application" a été démocratisé par les smartphones et sont bien identifiés du grand public pour rendre un service, un service Web qui serait ici un site vitrine, ou un blog, ou un annuaire de membres d'association, ...

Donc pour moi, ces packages de services tout prêts qui s'appuient sur les squelettes seraient des "applications", que l'on trouverait alors dans "extensions/applications".

3

Ça apporte un changement sur la compréhension de extensions/dist mais c'est vrai que ça n'apporte pas grand chose à squelettes-dist.

En effet, ce dernier ne contient *plus aucun* squelettes en sens où on l'entend habituellement (qui représentent plutôt le HTML des pages). Là ce dossier ne contient plus que du fonctionnel (des formulaires essentiellement, et un modèle). Donc le nom du contenant ne correspond plus au contenu. Et c'est à mon avis ça qui perturbe tout le monde.

4

Pour répondre à cela, il faudrait déterminer les différents besoins liés à l'utilisation de Spip en tant que CMS:
- blog ;
- portail ;
- magazine ;
- annuaire de membres ;
- etc.

Davux sous entend déjà ce besoin de définition.
Stéphane apporte un autre aspect des besoins : l'application.
Mais là aussi, on met un peu tout la dedans. Il faudrait déterminer ce qu'on entend par application. Ça serait une autre distribution pour un type de terminal? (smartphone uniquement?)

5

Pour répondre à cela, il faudrait déterminer les différents besoins liés
à l'utilisation de Spip en tant que CMS: - blog ;
- portail ;
- magazine ;
- annuaire de membres ;
- etc.

Davux sous entend déjà ce besoin de définition.

Du tout. :slight_smile: Ces distributions apparaîtront au fur et à mesure que des gens en ayant besoin les feront, je crois qu'on a pas de souci à se faire sur ça (et encore moins sur la liste spip-dev, ça aurait plutôt sa place sur spip-zone). MediaSPIP est un premier exemple. Côté dev, le boulot est uniquement de laisser l'espace pour que de telles distributions multiples puissent exister.

6

Non pas une distribution pour un type de terminal, mais une distribution pour un type de *service* Web (CMS), comme énuméré par Teddy : blog, portail, magazine, annuaire, ...

Et là, SPIP permettrait de couvrir le champ de tous les "concurrents"...

7

Plus aucun squelette au sens *habituel*, mais cette "habitude" était-elle vraiment significative ?

Là le nom squelette prendrait le vrai sens du contenu : la structure, un ensemble de vertèbres, et non le html final.

8

Entre les différents fils qui changent de sujet, je retrouve plus le
bon, d'ailleurs je suis pas sûr qu'il y en ait un dédié au sujet, alors
c'est l'esprit embué que je commence celui-ci, hop.

http://permalink.gmane.org/gmane.comp.web.spip.devel/61791
http://comments.gmane.org/gmane.comp.web.spip.devel/62102
http://permalink.gmane.org/gmane.comp.web.spip.devel/62132

À un moment, y'a longtemps, je crois qu'on s'était dit que SPIP était
désormais utilisé pour divers profils de sites,

Où est la liste des ces « profils » ?

et que pour suivre
cette réalité on voulait sortir du modèle de "Dist" unique au profit de
distributions multiples. Par distribution on entend un jeu de
squelettes et de plugins, formant un tout cohérent, et que le public
visé para la distribution en question (à chaque public sa distribution,
donc) puisse utiliser directement.

Idem, j'ai loupé un truc : où est la doc décrivant ce qu'est une « distribution » et ces « publics » ?

Du coup, bon, j'ai loupé le moment où il a été décidé de faire une
extension qui s'appelle "dist",

Moi aussi :slight_smile:

mais laissez-moi vous dire que c'est un
nom aussi informatif que le plus chiant des journaux de TF1. Quel
public est visé ? Alors du coup, effectivement, si on va faire une
extension "dist", je comprends la confusion de certaines personnes entre
"squelettes-dist" et "extensions/dist"... Le second n'apporte rien au
premier, car on reste sur le modèle d'un seul standard, donc à ce
compte-là c'est comme tout laisser dans squelettes-dist...

[...]

Bon, en un mot comme en cent, je voulais juste qu'on perde pas de vue
que si y'a actuellement un dossier "extensions/dist", c'est juste le
fait d'un piètre choix de nommage, et que ce fruit du travail
artistique des devs (ça veut bien dire ce que ça veut dire !) est le
premier d'un futur riche éventail de distributions adaptées à tous les
sites de la planète (en attendant d'en coloniser d'autres). Du coup je

Si je comprends bien, nous avons déjà le nommage adapté aux distributions, mais aucune distribution ? Je ne voudrais pas paraître trop bassement pragmatique, mais il y a des utilisateurs à SPIP : où leur est-il expliqué cette nouvelle nomenclature d'une chose qui n'existe pas encore ?

-- Romy

9

Ben ça fait partie de la doc à écrire, comme plein d'autres modifs dûes à cette version.

10

da@weeno.net wrote:

Du tout. :slight_smile: Ces distributions apparaîtront au fur et à mesure que des gens
en ayant besoin les feront, je crois qu'on a pas de souci à se faire sur
ça (et encore moins sur la liste spip-dev, ça aurait plutôt sa place sur
spip-zone). MediaSPIP est un premier exemple. Côté dev, le boulot est
uniquement de laisser l'espace pour que de telles distributions multiples
puissent exister.

Pour moi, en SPIP3, la "dist" n'évoque plus le squelette livré par défaut
avec SPIP mais l'ensemble de la distribution de SPIP, y compris un squelette
dénommé dist. Qu'on l'appelle dist, soyez_zouaves ou spip-castique, le
squelette de base qui sera distribué avec SPIP s'appelle comme on veut,
c'est le nom d'un squelette. Par contre, il doit avoir pour qualité de
fournir des squelettes et css pour tous les éléments activables dans le SPIP
livré en zip sur spip.net

Et si ça me chante, je fais ma propre distribution SPIP avec soyez_sarka et
tous ses plugins mis en extensions... Pour ce cas-là, on peut supposer que
je suis capable et compétent pour mettre à disposition tous les éléments et
formulaires nécessaires (quitte à reprendre à la main ceux de la dist qui
sont nécessaires au fonctionnement de SPIP). De même, à moi de livrer tous
les squelettes et css nécessaires au fonctionnement de ma distribution
"soyez sarka".

Dans les deux cas, vu que l'ensemble des éléments de squelette se trouvent
dans plein de dossiers épars, ce qui serait sympa, c'est de faire une courte
doc qui explique ça et une page qui liste tous les éléments actuellement
disponibles sur le SPIP tel qu'il est installé: un squelette-liste basé par
défaut sur les itérateurs ? Pour moi, on pourrait trouver ce seul élément
dans le dossier squelettes que SPIP pourrait créer d'office à l'installation
vu que c'est un dossier "système", avec ce squelette-list dedans.

Donc en résumé, pour moi:
- le *nom* du squelette distribué sur spip.net, osef et dist c'est bien
- le dossier squelettes-dist on peut le sucrer
- créons un dossier squelettes à l'installation de SPIP avec un squelettes-
liste.html dedans qui liste les squelettes dispo dans la distribution de
SPIP active

Ah, et :-*

11

Ecrire de la doc, je m'en occupe sans problemes,
dans deux cas :
1°/ si pour un développement ou un point d'intéret
     j'investigue (un peu solitaire) dans le code spip
      (ou le code d'un plugin....)
     => assez systématiquement je me fais une doc perso,
        donc souvent sur Carnet /mais pas facile a retrouver/

2°/ je veux bien, pour accroitre "ma" connaissance
de mon outil favori, mais s'il est possible de partir
de quelque chose sans devoir mener des recherches infinies
sur des textes (ou mails) de réflexion/discussion eparses
  dans l'ensemble du monde....

En clair, cela veut dire que, meme en lisant spip-devel,
c'est une tache de Sisyphe de synthétiser les multiples
flux sur un sujet, et meme seulement de s'en souvenir
(cf. l'indication hier de Suske sur les tickets).

Voila pourquoi je suggérerai avec insistance
que ces réflexions soient plutot déposées dans des pages
du Carnet (toujours en inspiration de Wikini..).
   Pour "suivre" la notification de remarques,
il me semble possible de coupler deux/trois outils
standard de SPIP, à savoir :
    - le comparateur de versions, pour "voir" les dernieres modifs
    -le suivi des notifications (pour continuer à etre informé par la liste)
    - voire un fil RSS qui faciliterait l'abonnement personnalisé
      aux thèmes (et branches) du Carnet d'interet prioritaire.

Cela ne signifie pas l'abandon de les listes spip,
qui ,outre l'habitude d'usage -utile-, portent
à découvrir de nombreuses nouveautes; mais peut-etre
un enrichissement par les notifications des ajouts
(a Contrib, voire a Plugins, Spip.Net ou Programmer)
les rendrait-elle plus propices à l'interactivité.

Mes dessous du matin
YannX

PS Et peut-etre qu'Edgard pourrait traiter de meme
certains passages d'IRC, pour archivage et information.

12

Hello,

je comprends juste que le déplacement/renommage du dossier contenant le squelette par défaut avec lequel SPIP sera distribué génère beaucoup de bruit et d'incompréhension.
De plus, cela a le mauvais goût de casser toute la doc existante qui mentionne squelettes-dist (on est plus à ça près, certains vont dire).
Je pense qu'il faut simplifier et remettre le contenu de extension/dist/ dans squelettes-dist pour permettre aux utilisateurs de retrouver leurs petits.

Continuer à trainer ce problème comme un boulet pour le pretexte de distributions éventuelles est un mauvais plan : pour qu'une distribution alternative existe il faut au moins que SPIP soit releasé dans une version stable, et on semble vraiment pas en prendre le chemin.

Accessoirement que les squelettes par défaut soient proposés dans squelettes-dist est un problème vraiment mineur pour qui voudrait faire une distribution, et ça ne mérite vraiment pas de créer tant de problèmes, questions et incompréhensions pour 99,9% des utilisateurs de SPIP au pretexte de simplifier la vie des 0,1% qui se chargeront de packager une distribution alternative.

Il sera toujours temps de refaire ce mouvement dans une autre direction quand on aura trouvé l'idée et le nommage qui seront compréhensibles pour tous.

Cédric

13

Je plussois.
Remettre extensions/dist dans squelettes-dist/ semble un excellent compromis, au moins pour l'instant :slight_smile:

MM.

14

Yep,

15

2012/3/22 Eric <eric@smellup.net>

Ben je plussoie aussi même si je pense que ce n’est pas une solution, c’est surement le meilleur compromis actuellement car la dist en extensions n’a pas de sens pour moi.

Maintenant, il est vrai comme je l’ai déjà dit que je préfèrerais

  1. que les pages « objet » publiques soient portées par l’extension associée, ce qui me parait plus cohérent et éviterait que celles-ci pointent sur rien quand l’extension est absente.
  2. que squelettes-dist ne propose que ce qui est inclus nativement dans le core nu comme article, sommaire…

Mais ça demande à être vérifié pour savoir si ça teint toujours la route.
Donc à tout le moins, la proposition de Cédric est meilleure que la solution actuelle.

++
Eric

Je crois que je n’ai pas très bien suivi ou compris : je pensais qu’un jour, à l’installation étape X, SVP serait chargé, et permettrait de choisir une dist parmis les dist. Que ces dist indiqueraient leur dépendance aux plugins / extensions qui s’installerait avec elle et que ce tout formerait une distribution cohérente, qu’on pourrait personnaliser par la suite par l’ajout de plugins. Des distributions à la volée en quelque sorte.
Faire porter les pages « objet » publiques par leur extension, pourquoi pas, mais comment on construit les pages sans savoir à quelle dist on s’adresse ? Je veux des pages « objet » publiques pour dist (alias rouge-mini by davux), dist2007 ou zpip, comment je fais pour qu’elle fonctionne dans tous ces cas de figure ?

16

Et voila qu’on repart a tirer des plans sur la comète et faire peser des contraintes d’une supposée utilisation non vérifiée.
Deux points :

  • A mon avis, une distribution, c’est un simple zip que l’on télécharge, avec plus ou moins de trucs dedans. Pas de rapport avec une étape X d’installation supplémentaire.
  • je pense que deplacer les pages des « objets » dans les extensions n’a pas de sens avec la dist actuelle qui n’est pas modulaire. Elle forme un tout, et ne fonctionne qu’avec tous les plugins présents nativement dans SPIP. Ce n’est pas l’objet de la dist que de gérer une pseudo-configuration variable (On sait tous que ce besoin amène de la complexité qui n’a rien a faire dans squelettes-dist)

Bref, comme je disais, il sera temps d’aller dans une direction ou une autre quand elles auront été effectivement explorées. Mais faire un choix sur des hypothèses non vérifiées est casse gueule.

Cédric

17

Yo,

Et voila qu’on repart a tirer des plans sur la comète et faire peser des contraintes d’une supposée utilisation non vérifiée.

Je vois pas de quoi tu parles.

Deux points :

  • A mon avis, une distribution, c’est un simple zip que l’on télécharge, avec plus ou moins de trucs dedans. Pas de rapport avec une étape X d’installation supplémentaire.

Oui, et donc ?

  • je pense que deplacer les pages des « objets » dans les extensions n’a pas de sens avec la dist actuelle qui n’est pas modulaire. Elle forme un tout, et ne fonctionne qu’avec tous les plugins présents nativement dans SPIP.

Enfin c’est sur qu’à prendre les incohérences existantes comme des présupposés ne peut pas faire avancer le débat.
Ce que je remets en cause c’est justement ça : on a découpé le core en plugins fonctionnels en considérant que la fonction s’arrêtait à sa mise en oeuvre interne et à son interface privée.
Je pense que conceptuellement c’est une erreur et que ça aboutit aujourd’hui au fait qu’on ne puisse distribuer qu’une version complète du public avec le core quel qu’il soit, c’est à dire avec toutes les extensions ou pas.

Ce n’est pas l’objet de la dist que de gérer une pseudo-configuration variable (On sait tous que ce besoin amène de la complexité qui n’a rien a faire dans squelettes-dist)

Je vois pas à quoi tu fais référence là ?

Bref, comme je disais, il sera temps d’aller dans une direction ou une autre quand elles auront été effectivement explorées. Mais faire un choix sur des hypothèses non vérifiées est casse gueule.

No comment…

En tout cas, je répète qu’à tout prendre, oui je préfère un squelette-dist/ inclus au core qu’une extensions/dist.

18

Pour prendre un exemple concret, mettre breve.html dans l’extensions breves n’amène à rien car si on modifie le squelettes-dist (organisation des inclusion, structure html etc…) la page breves sera toute cassée et plus cohérente, et cela supposera donc d’aller modifier le squelette présent dans l’extension breves.

Pour l’utilisation perso, la surcharge dans squelettes/ fonctionnera pareil, sauf que l’utilisateur devra aller chercher son squelette modèle dans toutes les extensions, et non plus à un seul endroit.
Mais pour fournir un squelette alternatif ça serait pire : il faudrait modifier toutes les extensions et non plus juste un dossier.
De même Z inhibe le squelettes-dist pour éviter de devoir surcharger tous les squelettes par défaut. Mais si on dispatche dans les extensions, il ne peut plus s’y retrouver non plus (il est perdu comme le webmestre)

Le découpage en extension s’est arrêté au squelette public pour la simple raison qu’il n’y a pas de mécanisme pour rendre le squelettes-dist extensible.
Dans le prive on a pris en compte tous les besoins de modularisation avec des pipelines, avec Z etc…

Mais faire le même travail dans le public supposerait de remplacer le squelettes-dist actuel par quelque chose de beaucoup plus compliqué.
Je pense que ce n’est pas du tout l’objectif du squelettes-dist actuel.

Cédric

19

Bon, le terme de squelette actuellement est utilisé à la fois pour désigner UN fichier squelette (truc.html) et pour désigner un ENSEMBLE de squelettes formant un tout cohérent. J'utiliserai donc le terme de "jeu de squelettes" pour l'instant.

Donc : un jeu de squelette est un *tout cohérent*. Il n'a de sens que pour les fonctionnalités qu'il propose d'afficher. Le jeu de squelette fourni actuellement par défaut *nécessite* les forums, les mots, les brèves, car il présente toutes ces informations de manière unique, dans des pages présentées pareilles, avec le même layout, etc (tout jeu de squelettes n'est pas forcément découpé comme Z !).

Pour l'instant on garde tout ensemble, mais c'est tout à fait logique que SI une distribution désire fournir un jeu de squelettes par défaut, alors ce jeu est forcément en rapport avec les plugins verrouillés (obligatoires donc) qui seront fournis par celle-ci.

Un plugin fonctionnel peut uniquement fournir des *morceaux* de squelettes plus ou moins génériques à inclure dans des pages ensuite. Mais un plugin fonctionnel ne pourra jamais fournir une *page* générique qui marcherait partout tout le temps pour tout jeu de squelettes installé ! Et contenu/patate.html en Z n'est qu'un *morceau* qui sera éventuellement inclus dans une vraie page Z grâce au mécanisme magique que l'on commence à connaître. Mais ce n'est pas une page complète.

Si on place une vraie page complète dans un plugin fonctionnel, alors cette page sera arbitraire, avec le layout de la nouvelle dist de tetue par exemple, et ce fichier-là ne sera donc pas générique. Cette manière de faire ne correspond pas au fait de pouvoir inclure le plugin dans une autre distribution n'ayant pas le même squelette par défaut.

Voilà pourquoi la dist devrait toujours rester un tout cohérent (que l'on va laisser dans squelettes-dist pour l'instant apparemment).

20

Yep,

Pour prendre un exemple concret, mettre breve.html dans l’extensions breves n’amène à rien car si on modifie le squelettes-dist (organisation des inclusion, structure html etc…) la page breves sera toute cassée et plus cohérente, et cela supposera donc d’aller modifier le squelette présent dans l’extension breves.

Ok, ce que tu veux dire c’est que sans moteur du type Z voire Z+noisetier cela n’a pas d’intérêt de mettre les pages ou blocs de page publics dans les extensions.

Mais faire le même travail dans le public supposerait de remplacer le squelettes-dist actuel par quelque chose de beaucoup plus compliqué.
Je pense que ce n’est pas du tout l’objectif du squelettes-dist actuel.

Oui alors là les objectifs… :stuck_out_tongue:
Mais on avait quand même parlé il y a… un temps certain de Z aussi pour la dist.
On abandonne complètement cette piste Z ou Z’ ?