[SPIP Zone] Le rangement des squelettes

RastaPopoulos1 · Avril 1, 2009, 4:10

C'est le squelettes Zesty qui m'y a fait repenser. En rangeant ses morceaux dans "pages".

En ce qui concerne le rangement des dossiers sous l'arborescence d'un PATH, il y a de l'obligatoire et du pas obligatoire. Je m'explique.

C'est assez bien documenté pour ce qui concerne le "fonctionnel" : les actions dans actions/, les balises dans balises/ etc.

Mais pour ce qui est du non-fonctionnel, de la présentation, il n'y a pas d'obligation. Ce qui est très bien et ça ne doit pas changer.

Mais ici, ensemble, ne pourrait-on pas définir au moins des *recommandations* ? Cela n'obligerait toujours à rien, mais pourrait permettre de s'y retrouver un peu quand on ouvre les travaux des autres.

En effet, on peut donc mettre nos squelettes n'importe où, avec n'importe quel formalisme. Donc comme de bien entendu, chacun fait son rangement dans son coin : tout à la racine avec des suffixes "inc-" pour les morceaux à inclure, tout dans fonds, dans noisettes, dans pages... On ne sait plus vraiment où est quoi.

Voici mes réflexions au fil de mes squelettes :

- les squelettes qui sont à la RACINE d'un chemin, sont *immédiatement accessibles* par "spip.php?page=le_squelette".
Cela signifie qu'il est totalement inutile, trompeur, et fouillis de laisser des morceaux à inclure à la racine. Furent-ils précédés de "inc-".
===> ils doivent être mis dans un sous-dossier.

- comme les morceaux à inclure sont dans des sous-dossiers, alors ils sont *forcément* à inclure ! C'est donc totalement redondant de leur ajouter "inc-" : les noms de fichiers sont moins lisibles alors que ça ne donne aucune information pertinente.
===> ils faut virer tous les "inc-"

- pas assez de sous-dossiers et c'est le bazar mais trop de sous-dossiers c'est incompréhensible. Il faut donc se mettre d'accord sur un minimum de dossiers cohérents qui *veulent dire* quelque chose.
===> noisettes/ pour les morceaux qui sont des noisettes. Une noisette est un morceau qui a du sens en lui-même. Il peut attendre des paramètres précis. Cela peut être "Afficher les articles d'une rubrique de manière courte", "Pareil mais de manière longue", "Afficher UN article entier", etc.
===> fonds/ pour les morceaux qui n'ont pas de sens. Par exemple les morceaux structurels. On peut faire des sous-dossiers dedans.
Typiquement, l'arborescence que marcimat a mis dans pages/, moi je la met dans fonds/. Car pourquoi créer des termes supplémentaires quand certains déjà utilisés correspondent.

Dans mes squelettes avec la méthode layout, j'ai qqc du genre :
/
    fonds/
       contenu/
          article.html
          rubrique.html
       extra/
       head/
       navigation/
       entete.html
       barre-nav.html => barre sous l'entete si elle existe
       pied.html
       structure.html => le layout (pourquoi un mot anglais ?)
    noisettes/
       article_voir.html
       rubrique_liste_articles.html
    article.html
    rubrique.html

Tout ceci est à discuter ensemble.

--
RastaPopoulos

19eb0d0ad6f2ebee089f · Avril 1, 2009, 7:07

RastaPopoulos a écrit :

C'est le squelettes Zesty qui m'y a fait repenser. En rangeant ses morceaux dans "pages".

[...]

Voici mes réflexions au fil de mes squelettes :

- les squelettes qui sont à la RACINE d'un chemin, sont *immédiatement accessibles* par "spip.php?page=le_squelette".
Cela signifie qu'il est totalement inutile, trompeur, et fouillis de laisser des morceaux à inclure à la racine. Furent-ils précédés de "inc-".
===> ils doivent être mis dans un sous-dossier.

Entièrement d'accord

- comme les morceaux à inclure sont dans des sous-dossiers, alors ils sont *forcément* à inclure ! C'est donc totalement redondant de leur ajouter "inc-" : les noms de fichiers sont moins lisibles alors que ça ne donne aucune information pertinente.
===> ils faut virer tous les "inc-"

Et aussi d'accord...

- pas assez de sous-dossiers et c'est le bazar mais trop de sous-dossiers c'est incompréhensible. Il faut donc se mettre d'accord sur un minimum de dossiers cohérents qui *veulent dire* quelque chose.
===> noisettes/ pour les morceaux qui sont des noisettes. Une noisette est un morceau qui a du sens en lui-même. Il peut attendre des paramètres précis. Cela peut être "Afficher les articles d'une rubrique de manière courte", "Pareil mais de manière longue", "Afficher UN article entier", etc.

Oui, c'est le terme que j'utilise aussi habituellement... que j'ai remplacé (sur zest) par "noix" pour faire plus court, et pour laisser le dossier libre de "noisettes" à cerdic qui voulait s'en saisir pour faire des noisettes programmables avec un XML... Mais les deux se rejoingent : des bouts de codes fonctionnels auquels on peut passer des arguments.

===> fonds/ pour les morceaux qui n'ont pas de sens. Par exemple les morceaux structurels. On peut faire des sous-dossiers dedans.
Typiquement, l'arborescence que marcimat a mis dans pages/, moi je la met dans fonds/.

C'est ça que tu appelles ne pas avoir de sens ?... bon... fonds ou pages, moi, ça m'est égal...

Car pourquoi créer des termes supplémentaires quand

certains déjà utilisés correspondent.

Il n'y a que CFG je crois qui utilises fonds/, je ne sais pas si ta remarque est pertinente.

Dans mes squelettes avec la méthode layout, j'ai qqc du genre :
/
   fonds/
      contenu/
         article.html
         rubrique.html
      extra/
      head/
      navigation/
      entete.html
      barre-nav.html => barre sous l'entete si elle existe
      pied.html
      structure.html => le layout (pourquoi un mot anglais ?)

Ah oui, pourquoi ? et le mettre dans le dossier aussi, très juste...

   noisettes/
      article_voir.html
      rubrique_liste_articles.html

Là... perso, je préfère découper noisettes/ par objet quand c'est possible... mais on peut tout simplement préfixer de l'objet comme tu proposes...

--
MM.

Bruno_Bergot · Avril 1, 2009, 7:09

Salut,

Je trouve le "ils doivent" un peu catégorique mais pourquoi pas...
Essayer de mettre en place une sorte de spec de ce côté là serait
utile aux personnes qui fouillent dans un squelette ou plugin pour la
première fois.

"mais trop de sous-dossiers c'est incompréhensible"

Complètement d'accord et une arborescence trop complexe n'aide pas les
bidouilleus à se retrouver dans un squelette/plugin qu'ils ne
connaissent pas même si le var_mode=inclure est leur ami.

Pour ce qui est de l'appellation "noisettes" j'ai souvenir d'une
discussion sur IRC lors de laquelle certaines personnes souhaitaient
ne pas mettre en avant ce terme qui n'est pas présent dans la doc
officielle et peut être pas connu de tout le monde. Je pense pourtant
que "noisette" est un terme souvent utilisé. Même s'il n'est pas dans
la doc il fait partie de la "culture SPIP". Et en plus c'est mignon.

Par contre le terme "fonds" est déjà utilisé pour ranger les fonds CFG
donc va falloir trouver autre chose.

++
----
b_b

Le 1 avril 2009 18:10, RastaPopoulos <vincent@ldd.fr> a écrit :

C'est le squelettes Zesty qui m'y a fait repenser. En rangeant ses morceaux
dans "pages".

En ce qui concerne le rangement des dossiers sous l'arborescence d'un PATH,
il y a de l'obligatoire et du pas obligatoire. Je m'explique.

C'est assez bien documenté pour ce qui concerne le "fonctionnel" : les
actions dans actions/, les balises dans balises/ etc.

Mais pour ce qui est du non-fonctionnel, de la présentation, il n'y a pas
d'obligation. Ce qui est très bien et ça ne doit pas changer.

Mais ici, ensemble, ne pourrait-on pas définir au moins des
*recommandations* ? Cela n'obligerait toujours à rien, mais pourrait
permettre de s'y retrouver un peu quand on ouvre les travaux des autres.

En effet, on peut donc mettre nos squelettes n'importe où, avec n'importe
quel formalisme. Donc comme de bien entendu, chacun fait son rangement dans
son coin : tout à la racine avec des suffixes "inc-" pour les morceaux à
inclure, tout dans fonds, dans noisettes, dans pages... On ne sait plus
vraiment où est quoi.

Voici mes réflexions au fil de mes squelettes :

- les squelettes qui sont à la RACINE d'un chemin, sont *immédiatement
accessibles* par "spip.php?page=le_squelette".
Cela signifie qu'il est totalement inutile, trompeur, et fouillis de laisser
des morceaux à inclure à la racine. Furent-ils précédés de "inc-".
===> ils doivent être mis dans un sous-dossier.

- comme les morceaux à inclure sont dans des sous-dossiers, alors ils sont
*forcément* à inclure ! C'est donc totalement redondant de leur ajouter
"inc-" : les noms de fichiers sont moins lisibles alors que ça ne donne
aucune information pertinente.
===> ils faut virer tous les "inc-"

- pas assez de sous-dossiers et c'est le bazar mais trop de sous-dossiers
c'est incompréhensible. Il faut donc se mettre d'accord sur un minimum de
dossiers cohérents qui *veulent dire* quelque chose.
===> noisettes/ pour les morceaux qui sont des noisettes. Une noisette est
un morceau qui a du sens en lui-même. Il peut attendre des paramètres
précis. Cela peut être "Afficher les articles d'une rubrique de manière
courte", "Pareil mais de manière longue", "Afficher UN article entier", etc.
===> fonds/ pour les morceaux qui n'ont pas de sens. Par exemple les
morceaux structurels. On peut faire des sous-dossiers dedans.
Typiquement, l'arborescence que marcimat a mis dans pages/, moi je la met
dans fonds/. Car pourquoi créer des termes supplémentaires quand certains
déjà utilisés correspondent.

Dans mes squelettes avec la méthode layout, j'ai qqc du genre :
/
fonds/
contenu/
article.html
rubrique.html
extra/
head/
navigation/
entete.html
barre-nav.html => barre sous l'entete si elle existe
pied.html
structure.html => le layout (pourquoi un mot anglais ?)
noisettes/
article_voir.html
rubrique_liste_articles.html
article.html
rubrique.html

Tout ceci est à discuter ensemble.

--
RastaPopoulos

_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Ma_ieul · Avril 1, 2009, 7:46

RastaPopoulos a écrit :

C'est le squelettes Zesty qui m'y a fait repenser. En rangeant ses morceaux dans "pages".

En ce qui concerne le rangement des dossiers sous l'arborescence d'un PATH, il y a de l'obligatoire et du pas obligatoire. Je m'explique.

C'est assez bien documenté pour ce qui concerne le "fonctionnel" : les actions dans actions/, les balises dans balises/ etc.

Mais pour ce qui est du non-fonctionnel, de la présentation, il n'y a pas d'obligation. Ce qui est très bien et ça ne doit pas changer.

Mais ici, ensemble, ne pourrait-on pas définir au moins des *recommandations* ? Cela n'obligerait toujours à rien, mais pourrait permettre de s'y retrouver un peu quand on ouvre les travaux des autres.

En effet, on peut donc mettre nos squelettes n'importe où, avec n'importe quel formalisme. Donc comme de bien entendu, chacun fait son rangement dans son coin : tout à la racine avec des suffixes "inc-" pour les morceaux à inclure, tout dans fonds, dans noisettes, dans pages... On ne sait plus vraiment où est quoi.

Voici mes réflexions au fil de mes squelettes :

- les squelettes qui sont à la RACINE d'un chemin, sont *immédiatement accessibles* par "spip.php?page=le_squelette".
Cela signifie qu'il est totalement inutile, trompeur, et fouillis de laisser des morceaux à inclure à la racine. Furent-ils précédés de "inc-".
===> ils doivent être mis dans un sous-dossier.

- comme les morceaux à inclure sont dans des sous-dossiers, alors ils sont *forcément* à inclure ! C'est donc totalement redondant de leur ajouter "inc-" : les noms de fichiers sont moins lisibles alors que ça ne donne aucune information pertinente.
===> ils faut virer tous les "inc-"

- pas assez de sous-dossiers et c'est le bazar mais trop de sous-dossiers c'est incompréhensible. Il faut donc se mettre d'accord sur un minimum de dossiers cohérents qui *veulent dire* quelque chose.
===> noisettes/ pour les morceaux qui sont des noisettes. Une noisette est un morceau qui a du sens en lui-même. Il peut attendre des paramètres précis. Cela peut être "Afficher les articles d'une rubrique de manière courte", "Pareil mais de manière longue", "Afficher UN article entier", etc.
===> fonds/ pour les morceaux qui n'ont pas de sens. Par exemple les morceaux structurels. On peut faire des sous-dossiers dedans.
Typiquement, l'arborescence que marcimat a mis dans pages/, moi je la met dans fonds/. Car pourquoi créer des termes supplémentaires quand certains déjà utilisés correspondent.

Dans mes squelettes avec la méthode layout, j'ai qqc du genre :
/
   fonds/
      contenu/
         article.html
         rubrique.html
      extra/
      head/
      navigation/
      entete.html
      barre-nav.html => barre sous l'entete si elle existe
      pied.html
      structure.html => le layout (pourquoi un mot anglais ?)
   noisettes/
      article_voir.html
      rubrique_liste_articles.html
   article.html
   rubrique.html

Tout ceci est à discuter ensemble.

--
RastaPopoulos

il faudrait aussi réfléchir à pouvoir, au moins au moment du devellopement, appelé des bouts de squelettes directement par ?page=xxx/yyy (pour le moment, on ne peut faire que ?page==xxx

j'aime bien pouvoir ainsi appeler juste un noisette pour bosser dessus

--
Maïeul
http://maieul.ouvaton.org

azerttyu · Avril 2, 2009, 8:09

S'lt

noisettes/

Au lieu de noisettes/ il me semblerait plus logique d'utiliser
inclure/ (c'est ce que je fais maintenant)

Comme dit par b_b noisettes/ n'a pas de sens à l'heure actuelle, pas
de documentations officielle
inclure est le nom utiliser pour afficher les inclusion via #INCLURE
avec le var_mode=inclure
et le inc de inc-*.hml signifie inclure

Donc en terme de sens et sans gymnastique intellectuelle

fonds/ (si j'ai bien compris)

J'utilise aussi une rubrique gabarit (qui me semble être l'équivalent
du layout ou strcuture abordé) pour regrouper les élements lié à la
mise en forme globale entete, pied de page, ...

contenu/

Contrairement à MM ou Rasta je découpe par objet rédactionnel. (je
crois que ça correspond plus ou prou aux secteurs) Dans ces rubriques
on retrouve un squelette pas objet spip et eventuellemetn des
surcharge de la rubrique gabarit

En reprenant la structure proposée par Rasta, ça ressemblerait plutot à ça.

/
  fonds/
  gabarit/
     navigation.html
     entete.html
     pied.html
     structure.html => le layout (pourquoi un mot anglais ?, pourquoi pas ?)
  mavie/
        article.html
        rubrique.html
  autretruc/
        article.html
        rubrique.html
        navigation.html
  inclure/
     article_voir.html
     rubrique_liste_articles.html
  article.html
  rubrique.html

Mes 2 sous

RastaPopoulos1 · Avril 2, 2009, 8:47

Le 02.04.2009 10:09, cam.lafit@azerttyu.net a écrit :

S'lt

noisettes/

Au lieu de noisettes/ il me semblerait plus logique d'utiliser
inclure/ (c'est ce que je fais maintenant)

Comme dit par b_b noisettes/ n'a pas de sens à l'heure actuelle, pas
de documentations officielle
inclure est le nom utiliser pour afficher les inclusion via #INCLURE
avec le var_mode=inclure
et le inc de inc-*.hml signifie inclure

Ben euuuh je dirais non. "inclure" c'est justement le mot qui a le moins de sens puisqu'on peut TOUT inclure.

Noisettes est un nom qui commence à circuler dfepuis un bout de temps, et même s'il n'y a pas de documentation, il suffit qu'un plugin qui les utilises intensivement en fasse la doc pour que ce soit public (qui a dit spip-zen ?).

On peut inclure tout et n'importe quoi, alors qu'une noisette c'est un morceau bien précis : un morceau qui a du sens en soi et non pas dans un contexte précis. Par exemple "liste des articles d'une rubrique" ça peut aussi bien se trouver dans le contenu que dans la navigation ou autre, peu importe, la noisette garde son sens. De la même façon une "barre de navigation" peut aussi bien s'inclure en dessous de l'entête, dans la div navigation ou encore dans le pied de page, ça gardera le même sens. Ça se sont des noisettes. Il suffira d'en faire la doc quelque part.

Pour mettre tout ce qui est structurel, j'avoue que "fonds" n'est pas le plus adapté. On pourrait tout simplement utiliser "structure/". Au moins tout le monde comprendrait de quoi on parle, et ça signifierait bien qu'il ne devrait pas y avoir ou le moins possible de contenu (venant de la base de données) dans ce dossier.

--
RastaPopoulos

JLuc · Avril 2, 2009, 8:54

bruno bergot a écrit :

Par contre le terme "fonds" est déjà utilisé pour ranger les fonds CFG
donc va falloir trouver autre chose.

là c'est le spip à l'envers...

La notion de fond est trés clairement introduite
dans la doc tout ce qu'il y a de plus officiel
et grand public :

"Depuis SPIP 1.8.2 la distribution inclut un fichier page.php3
qui permet d’appeler tout squelette en passant en paramètre le « fond »"

(dixit <INCLURE> d'autres squelettes - SPIP)

Non seulement c'est dans la doc, mais c'est dans la syntaxe de spip depuis !

<INCLURE{fond=hierarchie}{id_rubrique}>
<INCLURE{fond=pied}>
<INCLURE{fond=pied}{lang=es}>
yen a d'autres, dont, allez, un petit statique :
[(#INCLURE{fond=lettre}|version_texte)]

(ibid)

A côté de ces sacrements, CFG est un truc de bidouilleurs !

JLuc

Bruno_Bergot · Avril 2, 2009, 9:16

Salut,

Le 2 avril 2009 10:54, JLuc <jluc@no-log.org> a écrit :

bruno bergot a écrit :

Par contre le terme "fonds" est déjà utilisé pour ranger les fonds CFG
donc va falloir trouver autre chose.

là c'est le spip à l'envers...

La notion de fond est trés clairement introduite
dans la doc tout ce qu'il y a de plus officiel
et grand public :

"Depuis SPIP 1.8.2 la distribution inclut un fichier page.php3
qui permet d’appeler tout squelette en passant en paramètre le « fond »"

(dixit <INCLURE> d'autres squelettes - SPIP)

Non seulement c'est dans la doc, mais c'est dans la syntaxe de spip depuis !

<INCLURE{fond=hierarchie}{id_rubrique}>
<INCLURE{fond=pied}>
<INCLURE{fond=pied}{lang=es}>
yen a d'autres, dont, allez, un petit statique :
[(#INCLURE{fond=lettre}|version_texte)]

Oui pourquoi pas... mais là tu parles d'un dossier fond alors que
Rasta parlait d'un dossier fondS ... Du coup on va se retrouver avec
une arborescence du type :

fond
fonds
machin
noisettes
truc

Cela risque de porter à confusion. Et je n'ai pas encore vu de plugin
ou squelette qui colle ses noisettes dans fonds ou fond. Peut être une
mauvaise habitude des créateurs de plugins ou squelettes ? D'autant
plus que le terme "fond" n'est pas très parlant par rapport à des mots
comme "noisettes" ou "inclure".

(ibid)

A côté de ces sacrements, CFG est un truc de bidouilleurs !

Et les gens qui font des plugins ou des squelettes c'est quoi ? Des
bidouilleurs, non ? C'est bien ces personnes qui sont préoccupés par
cette histoire de rangement ou de spec de l'arborescence.

++

JLuc

_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

JLuc · Avril 2, 2009, 9:32

bruno bergot a écrit :

Oui pourquoi pas... mais là tu parles d'un dossier fond alors que
Rasta parlait d'un dossier fondS ...

Oups je me suis un peu étranglé mais je parlais surtout d'un terme.

noisette je trouve ça très mignon,
si le contour de la notion est précisé et explicité,
et en ce sens j'apprécie beaucoup l'initiative de classification
de la famille des inclusions, entamée dans son mail précédent par Rasta.
ça peut aider à y voir plus clair, à apprendre, concevoir, partager...

JLuc

cerdic · Avril 2, 2009, 10:03

Le 2 avr. 09 à 11:32, JLuc a écrit :

bruno bergot a écrit :

Oui pourquoi pas... mais là tu parles d'un dossier fond alors que
Rasta parlait d'un dossier fondS ...

Oups je me suis un peu étranglé mais je parlais surtout d'un terme.

noisette je trouve ça très mignon,
si le contour de la notion est précisé et explicité,

Justement,
le terme de noisette n'est pas dans la lexicographie officielle de SPIP, car il désigne quelque chose de plus complet qu'un simple morceau de squelette à inclure.
Son origine vient de
http://romy.tetue.net/partager-facilement-ses-noisettes
étendu par
http://www.spip-contrib.net/SpipKits
(à moins que ce ne soit l'inverse ?)

Les noisettes auraient donc vocation à être des morceaux fonctionnels prêts à l'emploi, embarquant si nécessaire leur css, _fonctions, et js associés.
Dans l'étude que je mène sur spip-zen
(décrite en partie ici L’après SPIP 2.0 - SPIP-Contrib, qui a avancé depuis, mais helas pas assez pour permettre une publication satisfaisante), je suis arrivé à la conclusion qu'un xml descriptif de la noisette etait aussi nécessaire pour pouvoir en gérer tous les branchements depuis une interface.

Le fait qu'une noisette soit constituée de plusieurs fichiers (a minima un html+un xml) tendrait à préferer l'utilisation de sous dossiers.
Par exemple, une noisette portfolio serait en réalité constituée de
noisettes/portfolio/portfolio.html
noisettes/portfolio/portfolio.xml
noisettes/portfolio/portfolio.js

On en arriverait donc à désigner 'noisette' un ensemble de fichiers formant une unité logique fonctionnelle réutilisable regroupés dans un dosssier.

Ceci dit, pour justifier qu'utiliser le nom noisettes/ afin d'y ranger de simples morceaux de squelettes à inclure est sans doute une vue simpliste qui n'augure pas de ce que serait une noisette telle qu'elle apparaît à ce jour dans la littérature autour de SPIP (puisque non inclue dans les notions de SPIP à ce jour).
Ce serait donc un choix peu opportun qui amènerait un certain nombre de confusions et de difficultés de compréhension lorsque l'on souhaitera réellement introduire le concept dans un formalisme défini.

Je conseille donc d'éviter de choix de nommage.
D'un point de vue informel, chacun fait bien ce qu'il veut.
Mais si il s'agit d'établir une recommandation "officielle", alors je m'oppose vivement à ce choix.

Cédric

JLuc · Avril 4, 2009, 10:08

Salut Ced,

cedric.morin@yterium.com a écrit :

Les noisettes auraient donc vocation à être des morceaux fonctionnels prêts à l'emploi, embarquant si nécessaire leur css, _fonctions, et js associés.

ça devient des organismes vraiment autonomes et dynamiques.

je me demande d'ailleurs si ils sont toujours de l'ordre du fruit
végétal (noisettes) ou de l'ordre de l'animal (comme le squelette) ?
ça semble un peu entre les 2, pas le noisetier en tout cas,
mais peut être un muscle ?
Ou de l'ordre de l'habitat, comme un nichoir.

Dans l'étude que je mène sur spip-zen
(décrite en partie ici L’après SPIP 2.0 - SPIP-Contrib, ...)

> je suis arrivé à la conclusion qu'un xml descriptif de

la noisette etait aussi nécessaire pour pouvoir en gérer tous les branchements depuis une interface.
Le fait qu'une noisette soit constituée de plusieurs fichiers (a minima un html+un xml) tendrait à préferer l'utilisation de sous dossiers.
Par exemple, une noisette portfolio serait en réalité constituée de
noisettes/portfolio/portfolio.html
noisettes/portfolio/portfolio.xml
noisettes/portfolio/portfolio.js

J'ai l'impression que chaque fois qu'a chaque fois avec le xml,
ça donne des trucs lourds...

Là ça me fait penser aux couples php3 / html d'antan,
qui a été fort avantageusement remplacé par quelques instructions judicieuses
comme #CACHE{nnnnn} placées au début du html.

Ya peut être une comprenette à en tirer ?

On en arriverait donc à désigner 'noisette' un ensemble de fichiers formant une unité logique fonctionnelle réutilisable regroupés dans un dosssier.

Le terme plait !

JL

228b65607c479443a062 · Avril 7, 2009, 8:45

Bonjour,
Depuis le passage en SPIP 2 (spip 2.06 rev 13835, porte plume rev 27647 et enluminures V3 rev 27579), le raccourci SC ne fonctionne plus, dans la source, il y a bien les balises <SC> et </SC> mais elles ne sont pas remplacées par <span class="spip" style="font-variant: small-caps">

Quelqu'un a une idée ?

Merci d'avance,

Laurent Casagrande
CRDP de Bourgogne - Dijon

Bertrand_Marne · Mai 17, 2009, 8:06

Bonjour à tous,

J'aimerai revenir sur la conversation lancée il y a plus d'un mois par
Vincent (RastaPopoulos).

Je suis en train de toiletter en profondeur tous les squelettes (et un
plugin) dont je m'occupe pour un passage à Spip 2 et j'aimerai bien
faire quelque chose de propre dès le départ.

Je me pose donc notamment la question de l'arborescence "idéale".
C'est pourquoi j'aimerai savoir si le débat là dessus a continué
(ailleurs que sur la zone ?).

Je vous propose le résumé suivant de la conversation:

----------------8<----------------------
RastaPopoulos:
/
  fonds/
     contenu/
        article.html
        rubrique.html
     extra/
     head/
     navigation/
     entete.html
     barre-nav.html => barre sous l'entete si elle existe
     pied.html
     structure.html => le layout (pourquoi un mot anglais ?)
  noisettes/
     article_voir.html
     rubrique_liste_articles.html
  article.html
  rubrique.html

avec:

- les squelettes à la racine
- les inclures dans un sous-dossier (et qui ne se nomment pas inc-*)
- beaucoup de sous dossiers (mais pas trop...)
- "noisettes"-> morceaux qui ont du sens (car c'est un nom usité)
- "fonds"-> autres types de morceaux (bien que ce ne soit pas le plus
explicite et "structure" serait bien aussi)

------------------------------------------------------
Marcimat:

- Peut-être "noix" plutôt que "noisettes"
- "fonds" ou "pages" comme on veut (mais plutôt pas "fonds" quand même... :-))
- faire des sous-sous-dossiers dans "noisettes"

je crois que Matthieu n'aime pas que le layout (structure.html) soit
dans un sous dossier (j'ai bon ?)

---------------------------------------------------------
b_b:

- Il faut faire une spec
- Pas trop de sous dossiers
- pas d'accord pour "fonds" avec un S (plutôt utilisé par cfg) car il
y aurait "fond" et "fonds" dans l'arbo et parce que ce n'est pas très
parlant
----------------------------------------------------------
cam.lafit:

/
fonds/
gabarit/
    navigation.html
    entete.html
    pied.html
    structure.html => le layout (pourquoi un mot anglais ?, pourquoi pas ?)
mavie/
       article.html
       rubrique.html
autretruc/
       article.html
       rubrique.html
       navigation.html
inclure/
    article_voir.html
    rubrique_liste_articles.html
article.html
rubrique.html

- "inclure" au lieu de "noisettes"
- "gabarit" pour ce qui est lié au layout
- le reste est classé dans des sous-rép par contenu
---------------------------------------------------------
Jluc:

- "fond" (sans S) est clairement défini dans la doc
- "noisettes" c'est sympa mais il faut préciser officiellement ce que c'est
- noisette= végétal, squelette=animal ?
- si les noisettes sont xml/squelette, attention à ne pas retomber
dans php3/html de Spip<1.9 (plugin composants ?)
---------------------------------------------------------
Cédric:

- noisettes est défini comme quelque chose de plus complet qu'un
simple morceau de squelette à inclure (voir Tétue). Voir aussi le
plugin composants je suppose ?
------------------->8------------------

Et le bilan suivant:

- les intervenants étaient d'accord sur un découpage en sous-rubriques
- d'accord aussi sur la séparation des inclusions de
structure/layout/gabarit dans un sous-répertoire différent de celles
du sens/contenu.
- beaucoup souhaitent mettre à part les noisettes/noix qui sont des
éléments autonomes à condition qu'on leur passe les bons paramètres.
- "fonds" fait débat.
- "noisettes" semble apprécié mais fait débat aussi.

donc ils semblent d'accord sur:

/
  sous-rep-structurel (nom à définir)/
    des éléments.html
    de structure.html
    à inclure.html (dans des sous rép ?)
  soit noisettes ou noix/
  soit contenus/
article.html
rubrique.html
sommaire.html

avec éventuellement les sous répertoires d'inclusions (structurel et
contenus/noisettes eux-mêmes dans un sous répertoire fonds/pages)

Qu'en pensez-vous ?

--
Bertrand Marne

cerdic · Mai 17, 2009, 8:26

fonds/ est le nom du dossier utilisé par cfg pour y chercher les formulaires de configuration.
Il est préférable de ne pas l'utiliser pour autre chose, pour des soucis de perf et de lisibilité.
Cédric

Le 17 mai 09 à 10:06, MARNE Bertrand a écrit :

Bonjour à tous,

J'aimerai revenir sur la conversation lancée il y a plus d'un mois par
Vincent (RastaPopoulos).

Je suis en train de toiletter en profondeur tous les squelettes (et un
plugin) dont je m'occupe pour un passage à Spip 2 et j'aimerai bien
faire quelque chose de propre dès le départ.

Je me pose donc notamment la question de l'arborescence "idéale".
C'est pourquoi j'aimerai savoir si le débat là dessus a continué
(ailleurs que sur la zone ?).

Je vous propose le résumé suivant de la conversation:

----------------8<----------------------
RastaPopoulos:
/
fonds/
    contenu/
       article.html
       rubrique.html
    extra/
    head/
    navigation/
    entete.html
    barre-nav.html => barre sous l'entete si elle existe
    pied.html
    structure.html => le layout (pourquoi un mot anglais ?)
noisettes/
    article_voir.html
    rubrique_liste_articles.html
article.html
rubrique.html

avec:

- les squelettes à la racine
- les inclures dans un sous-dossier (et qui ne se nomment pas inc-*)
- beaucoup de sous dossiers (mais pas trop...)
- "noisettes"-> morceaux qui ont du sens (car c'est un nom usité)
- "fonds"-> autres types de morceaux (bien que ce ne soit pas le plus
explicite et "structure" serait bien aussi)

------------------------------------------------------
Marcimat:

- Peut-être "noix" plutôt que "noisettes"
- "fonds" ou "pages" comme on veut (mais plutôt pas "fonds" quand même... :-))
- faire des sous-sous-dossiers dans "noisettes"

je crois que Matthieu n'aime pas que le layout (structure.html) soit
dans un sous dossier (j'ai bon ?)

---------------------------------------------------------
b_b:

- Il faut faire une spec
- Pas trop de sous dossiers
- pas d'accord pour "fonds" avec un S (plutôt utilisé par cfg) car il
y aurait "fond" et "fonds" dans l'arbo et parce que ce n'est pas très
parlant
----------------------------------------------------------
cam.lafit:

/
fonds/
gabarit/
   navigation.html
   entete.html
   pied.html
   structure.html => le layout (pourquoi un mot anglais ?, pourquoi pas ?)
mavie/
      article.html
      rubrique.html
autretruc/
      article.html
      rubrique.html
      navigation.html
inclure/
   article_voir.html
   rubrique_liste_articles.html
article.html
rubrique.html

- "inclure" au lieu de "noisettes"
- "gabarit" pour ce qui est lié au layout
- le reste est classé dans des sous-rép par contenu
---------------------------------------------------------
Jluc:

- "fond" (sans S) est clairement défini dans la doc
- "noisettes" c'est sympa mais il faut préciser officiellement ce que c'est
- noisette= végétal, squelette=animal ?
- si les noisettes sont xml/squelette, attention à ne pas retomber
dans php3/html de Spip<1.9 (plugin composants ?)
---------------------------------------------------------
Cédric:

- noisettes est défini comme quelque chose de plus complet qu'un
simple morceau de squelette à inclure (voir Tétue). Voir aussi le
plugin composants je suppose ?
------------------->8------------------

Et le bilan suivant:

- les intervenants étaient d'accord sur un découpage en sous-rubriques
- d'accord aussi sur la séparation des inclusions de
structure/layout/gabarit dans un sous-répertoire différent de celles
du sens/contenu.
- beaucoup souhaitent mettre à part les noisettes/noix qui sont des
éléments autonomes à condition qu'on leur passe les bons paramètres.
- "fonds" fait débat.
- "noisettes" semble apprécié mais fait débat aussi.

donc ils semblent d'accord sur:

/
  sous-rep-structurel (nom à définir)/
    des éléments.html
    de structure.html
    à inclure.html (dans des sous rép ?)
  soit noisettes ou noix/
  soit contenus/
article.html
rubrique.html
sommaire.html

avec éventuellement les sous répertoires d'inclusions (structurel et
contenus/noisettes eux-mêmes dans un sous répertoire fonds/pages)

Qu'en pensez-vous ?

--
Bertrand Marne
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

JLuc · Mai 17, 2009, 4:36

Le 17 mai 09 à 10:06, MARNE Bertrand a écrit :

cedric.morin@yterium.com a écrit :

fonds/ est le nom du dossier utilisé par cfg pour y chercher les formulaires de configuration.
Il est préférable de ne pas l'utiliser pour autre chose, pour des soucis de perf et de lisibilité.
Cédric

C'est pourquoi j'aimerai savoir si le débat là dessus a continué

Cédric justement a publié le plugin "compositions".

JL

Bertrand_Marne · Mai 17, 2009, 5:52

Le 17 mai 2009 18:36, JLuc <jluc@no-log.org> a écrit :

C'est pourquoi j'aimerai savoir si le débat là dessus a continué

Cédric justement a publié le plugin "compositions".

Heu... Si je comprends bien le plugin répond à un besoin de squelettes
modulables avec des noisettes (c'est ce dont Cédric et Marcimat
parlaient au sujet des duos html/xml à placer dans "noisettes/").

Pas au cas général de tous les squelettes. Et donc il n'en définit pas
l'arborescence type.

Je me trompe ?

--
Bertrand Marne

cerdic · Mai 17, 2009, 7:03

Le 17 mai 09 à 19:52, MARNE Bertrand a écrit :

Le 17 mai 2009 18:36, JLuc <jluc@no-log.org> a écrit :

C'est pourquoi j'aimerai savoir si le débat là dessus a continué

Cédric justement a publié le plugin "compositions".

Heu... Si je comprends bien le plugin répond à un besoin de squelettes
modulables avec des noisettes (c'est ce dont Cédric et Marcimat
parlaient au sujet des duos html/xml à placer dans "noisettes/").

Non, le plugin permet de gérer aussi le squelette complet, ou un morceau de squelette.

Pas au cas général de tous les squelettes. Et donc il n'en définit pas
l'arborescence type.

Il propose un dossier compositions/ mais personalisable dans sa dénomination, donc effectivement...

Je me trompe ?

ptet ben que oui, ptet ben que non

Cédric

RastaPopoulos1 · Mai 18, 2009, 5:53

Le 17/05/2009 10:26, cedric.morin@yterium.com a écrit :

fonds/ est le nom du dossier utilisé par cfg pour y chercher les
formulaires de configuration.
Il est préférable de ne pas l'utiliser pour autre chose, pour des soucis
de perf et de lisibilité.
Cédric

D'une : ce n'est pas du tout intuitif le fait que le dossier associé à CFG s'appelle "fonds" (quel rapport ?). Il aurait été tellement simple de l'appeler "cfg".
De deux : dans tous les cas ça fait lonnnngtemps (et entre autre, plus longtemps que CFG) que le mot "fond" fait partie de la terminologie spipienne pour désigner "un morceau à inclure". Tout simplement parce que c'est dans la syntaxe même des INCLURE (fond=...).

Pour le créateur de squelette lambda, il parait alors logique d'aller chercher son "fond=..." dans les "fonds/".

Donc le cas de CFG ne me parait pas une bonne "excuse".

Mais bon, après, chacun fait comme il veut hein...

--
RastaPopoulos

romy · Mai 18, 2009, 6:23

Le 17 mai 2009 à 10:06, MARNE Bertrand a écrit :

Je suis en train de toiletter en profondeur tous les squelettes (et un
plugin) dont je m'occupe pour un passage à Spip 2 et j'aimerai bien
faire quelque chose de propre dès le départ.

Je me pose donc notamment la question de l'arborescence "idéale".
C'est pourquoi j'aimerai savoir si le débat là dessus a continué
(ailleurs que sur la zone ?).

Je vous propose le résumé suivant de la conversation:
(...)
Qu'en pensez-vous ?

Je n'avais pas participé à la conversation, mais voici à quoi ressemble mon arbo type depuis 1 ou 2 ans :

/2009/
/2009/ 404.html
/2009/ habillage.css
/2009/img/...
/2009/inc-article.html
/2009/inc-documents.html
/2009/inc-entete.html
/2009/inc-head.html
/2009/inc-memrub.html
/2009/inc-pied.html
/2009/inc-rubriques.html
/2009/inc-tagcloud.html
/2009/lang/...
/2009/mes_fonctions.php
/2009/modeles/...
/2009/login.html
/2009/page_accueil.html
/2009/page_agenda.html
/2009/page_article.html
/2009/page_blog.html
/2009/page_contact.html
/2009/page_forum.html
/2009/page_liens.html
/2009/page_galerie.html
/2009/page_liens.html
/2009/page_tagcloud.html
/2009/polices/...
/2009/recherche.html

---> j'appelle toujours mon répertoire squelettes du nom de l'année de création (ou de refonte) ; c'est vraiment pratique pour s'y retrouver
---> mes inclusions pourraient être rangées dans un sous-rep « inc », mais j'aime les voir : je les étale donc à la racine du répertoire.
---> je travaille par « page », zappant complètement les squelettes natifs de SPIP. Chaque page est un gabarit spécial, imposé par la maquette fonctionnelle, dont la sctructure HTML est différente (peu ou prou), bénéficiant d'une class aïeule homonyme (donc facile à styler) et pouvant afficher n'importe quel type d'objet SPIP (natif ou plugin).
---> L'exemple d'arbo ci-dessus correspond à un site complexe. Un site simple n'a que 1 ou 2 « pages ». Oui, ça fait très peu de fichiers au total. C'est + simple à comprendre et à maintenir.

Je synthétiserais-normaliserais donc ainsi :

/squelettes/
/squelettes/img/...
/squelettes/inc/...
/squelettes/lang/...
/squelettes/modeles/...
/squelettes/pages/...
/squelettes/polices/...

- Non pour « noisettes » tant que ce terme ne bénéficie pas d'une définition 'officielle' + ras le bol des néologismes spipiens : le terme « inclusion » existe déjà et convient fort bien.
- Et non, évitons les « noix » et autres « coquilles »
- D'accord avec RastaPopoulos au sujet de « fonds », qui devrait s'appeler « cfg » dans les plugins. Mais je ne vois pas très bien pourquoi introduire un tel sous-rep dans notre bon vieux dossiers « squelettes »... Ça veut dire quoi ? Où est-ce 'clairement défini dans la doc' ?
- Oui, préférons « structure » à « layout »... D'expérience, le mot « page » parle mieux aux non-professionnels que « gabarit ».
- Bien que je n'en ai jamais eu l'utilité, je comprends la nécessité, pour d'autres approches, d'un sous-rep « contenus ».
- Je n'ai pas encore fait le tour des « compositions » et ne sait pas quoi en penser.

Mes deux sous.

--
Romy

19eb0d0ad6f2ebee089f · Mai 18, 2009, 7:15

MARNE Bertrand a écrit :

Marcimat:

je crois que Matthieu n'aime pas que le layout (structure.html) soit
dans un sous dossier (j'ai bon ?)

Non, au contraire même, l'argument d'azerttyu ou rastapopoulos je ne sais pas est suffisant pour dire non : à partir du moment où un squelette n'est pas appelé par ?page=xxx mais uniquement depuis un <INCLURE> alors on le met dans un répertoire.

layout.html ou structure.html est donc mieux dans un dossier à mon sens...

---

Pour répondre à Rastapopoulos à propos des fonds de CFG, je serais aussi partisan de les mettre dans un dossier cfg/ plutôt que fonds/ ... Cela pourra faire partie du passage en CFG 2.0 (si si, un jour il existera !). Quitte à casser des compatibilités, autant tout faire d'un coup...

--
MM.