Bonjour,
je suis en plein préparatifs de voyage (je pars deux semaines à l’étranger pour mon travail) et avant de partir je vais essayer de commiter l’import/export de configuration au format YAML et la possibilité de créer des compositions qui ne différeraient que par leurs noisettes.
Encore une fois, ce n’est qu’un prototype susceptible d’évoluer.
Le principe du noizetier est avant tout d’offrir au webmaster du site une interface dans l’espace privé lui permettant d’ajouter des noisettes en différents endroits du site. Ces noisettes sont bien surs paramétrables.
Pour avoir une idée de l’objectif que je recherche, tu peux essayer sur un site de test d’installer Zpip, noizetier et le plugin aveline (pour le moment ranger sur la zone avec le noizetier) et de te rendre sur ecrire/?exec=noizetier
Le principe du squelette aveline est de fournir un squelette Z vide de contenu, tous les contenus étant ajoutés sous formes de noisettes, fournies par ce squelette. Seules quelques noisettes sont disponibles aujourd’hui dans aveline mais il y a de quoi tester le principe avec la page article.
Cela permettra de visualiser un peu mieux comment fonctionne le noizetier. Le noizetier ne vise que l’inclusion de noisettes paramétrées définies via une interface dans l’espace privée, inclusion venant en plus du contenu principal défini via les squelettes. Il ne s’intéresse donc pas au paramétrage de ces squelettes, ce que sarka fait très bien via CFG.
Quelques soient le squelette utilisé, il importe de :
-
déterminer les pages et les blocs qui peuvent recevoir des noisettes, pour l’interface de configuration qui stockera la configuration dans une table spip_noisettes. Dans Zpip, la liste des pages s’obtient en analysant le répertoire contenu et la liste des blocs est connue (contenu, navigation, extra). Pour d’autres squelettes, cela peut être différent.
-
insérer les noisettes aux bons endroits. Avec un squelette Z, cela est fait via le pipeline recuperer_fond car le bloc correspond à un sous-répertoire et que les variables type et composition sont disponibles comme variables d’environnement. Pour d’autres squelettes, il faut déterminer si le plus simple est de passer par ce pipeline ou bien par un <INCLURE{fond=noizetier-
generer-bloc}{bloc=‹ nombloc ›}{type=‹ typepage ›}{composition=‹ compo ou vide ›}{env}>. Le problème de l’inclure, c’est qu’il faut vérifier la présence du plugin avant de le faire.
Dans le répertoire noisettes de sarkaspip, il y a des éléments qui sont inclus d’office dans les pages.
Dans la logique du noizetier, le répertoire noisettes contient uniquement des contenus que le webmaster du site peut optionnellement ajouter aux différentes pages.
Concernant une bibliothèque de noisettes, je ne pense pas que c’est au noizetier de les fournir, à part peut être la noisettes rajoutant un bloc de texte.
Certaines noisettes génériques devraient être fournies par le plugin concerné. Par exemple dans le plugin Menus une noisettes permettant d’afficher un menu.
Les noisettes spécifiques dépendent pour leur part d’un squelette. Il y a d’une part la convention de nommage des noisettes qui peut différer d’un squelette à l’autre. Zpip est en train de se doter d’une convention de nommage http://www.spip-contrib.net/Conventions-de-nommage-dans-Zpip qui ne concernent que les squelettes Z. Je ne connais pas la convention de nommage de Sarka mais je suppose qu’elle diffère (puisqu’il ne s’agit pas des mêmes thèmes).
Une noisette qui affiche le contenu principal d’un article est pertinente dans Aveline puisque tous les contenus sont déterminés sous forme de noisettes. Mais si on utilise Zpip seul ca n’a pas de sens puisque le contenu principal est déjà fourni.
La question de savoir qui fourni telle noisette mérite probablement d’être développée.
Concernant le nommage des noisettes, pour le moment le noizetier utilisage une convention de nommage afin de déterminer sur quelles pages il peut proposer cette noisette. Voir http://www.spip-contrib.net/noiZetier
Ranger des noisettes dans des sous-répertoires correspondrait à quelle logique ? Quelle serait la convention de rangement ?
Cordialement
Joseph
Le 20 mars 2010 10:28, Eric Lupinacci <eric@smellup.net> a écrit :
Hello Joseph,
Merci beaucoup pour tes explications mais j’ai vraiment du mal à rentrer dedans.
Dans Sarka-SPIP aujourd’hui j’ai beaucoup de noisettes et j’ai introduit des pipelines pour insérer des squelettes à certains endroits (navigation, extra en particulier).
Donc le noisetier pourrait apporter beaucoup, c’est une réflexion que j’ai aussi depuis longtemps car ça devrait:
- Une bibliothèques de noisettes réutilisables
- La possibilité de trier les rubriques dans un ordre choisi par le webmestre (je n’ai pas comment d’ailleurs pour l’instant?)
Le fonctionnement par défaut du noizetier avec un squelette Z :
les pages qui peuvent recevoir des noisettes sont celles ayant un squelette.html présent dans le sous–répertoire contenu. Par défaut, on peut ajouter des noisettes à trois blocs : contenu, extra et navigation.
Je comprends pas cette limite de la liste des pages. On pourrait pas plutôt définir la liste autrement de façon plus générique ?
Ok, donc les blocs ce sont ceux au sens de Z, les div d’id contenu, navigation et extra. Là aussi on pourrait définir la liste des blocs de façon plus générique non?
Via le pipeline ‹ recuperer_fond ›, le noizetier détecte l’appel au fond de type ‹ bloc/page › et ajoute au flux les noisettes correspondantes. Plus précisément, dans le pipeline ‹ recuperer_fond › le noizetier ajoute au flux l’appel au squelette ‹ noizetier-generer-bloc.html › en lui passant les variables d’environnement et les variables ‹ bloc › ‹ type › et ‹ composition ›.
Euh… en lisant la liste des noisettes dans noisettes/ ?
Utilisation du noizetier avec d’autres squelettes.
Cas 1 :
comme pour les squelettes Z, les contenus de chaque bloc sont définis par un squelette ‹ page.html › (plus précisément ‹ type-composition.html ›) situés dans des sous-répertoires ‹ bloc/ ›.
Voila un autre truc qui me gêne. Dans Sarka, les albums sont des articles avec un affichage particulier. Ca serait donc une composition article_album. Mais si je n’utilise pas compositions je peux quand même gérer les noisettes d’une page nommée album ?
En tout cas, il faut absolument réorganiser le squelette avec des sous-rep bloc/ si je comprends bien.
Sous-cas 1.1 : Les contenus principaux, dont les compositions, sont situés dans le sous-répertoire ‹ contenu/ ›.
Le noizetier va correctement détecter les pages pouvant recevoir des noisettes. Les blocs par défaut des différentes pages sont modifiables facilement via le pipeline ‹ noizetier_blocs_defaut ›. Le noizetier va repérer naturellement l’appel aux squelettes ‹ bloc/page › et rajoutera automatiquement les noisettes.
Je suis pas tout là…
Sous-cas 1.2 : la liste des pages pouvant recevoir des noisettes sont définies différemment ou il n’y a pas de sous-répertoire ‹ contenu ›. Il existe un pipeline ‹ noizetier_lister_pages › qui permet de modifier ou de changer le tableau contenant les informations (dont les blocs) des pages pouvant recevoir des noisettes. Le contenu des différents blocs est toujours organisé selon la logique ‹ bloc/page ›. Le noizetier interceptera l’appel à ces squelettes et ajoutera automatiquement les noisettes aux blocs en question.
Ok, donc là je peux utiliser mes noms de page et de bloc mais je dois absolument redéfinir mon arbo ?
Cas 2 :
l’organisation des squelettes et des inclusions suit une logique différente de celles des squelettes Z. Par exemple, une partie du contenu des pages est directement codé dans les squelettes racine (article.html etc) et diverses inclusions sont faites.
Le noizetier ne saura pas tout seul interpréter cette organisation des fichiers.
Il faudra utiliser le pipeline ‹ noizetier_lister_pages › pour lui passer le tableau décrivant les pages (et les blocs de chacune) surlesquelles il est possible d’ajouter des noisettes.
ATTENTION : si le nom de certaines pages contient un tiret ‹ - ›, alors le noizetier décomposera ce nom sous la forme type-page.
Il faut ensuite, au calcul des squelettes, détecter où ajouter les noisettes. Trois manières de procéder :
Sous-cas 2.1 : le squelette a recours au pipeline ‹ recuperer_fond › pour appeler ‹ noizetier-generer-bloc › avec les bon paramètres. ne fonctionne que si les blocs sont situés à la fin d’une inclusion.
Sous-cas 2.2 : utiliser un <INCLURE{fond=noizetier-generer-bloc}{bloc=‹ nombloc ›}{type=‹ typepage ›}{composition=‹ compo ou vide ›}{env}> dans les squelettes là où il faut ajouter des noisettes.
Sous-cas 2.3 : utiliser des boucles (NOISETTES) et la balise #NOIZETIER_AFFICHER_NOISETTE dans les squelettes.
Ah oui ! 2.2 et 2.3 c’est finalement le plus simple pour un squelette non Z. J’ai des inclusions extra.html et navigation.html qui font finalement de façon plus frustre ce que le noisetier fait de façon plus pertinente. Si tu as deux secondes pour regarder le code de Sarka…
En fait, je suppose alors qu’il me suffirait d’avoir une interface de choix du rang de la noisette pour paramétrer la liste. Mais comment je peux faire pour activer ou désactiver une noisette ?
On peut envisager une constante dans un fichier options.php pour désactiver le traitement effectué par le noizetier dans le pipeline ‹ recuperer_fond › pour les squelettes dans le cas 2.
Le Z dans noiZetier fait référence au fait que le noiZetier fonctionne nativement avec les squelettes suivant la norme Z. Cela pose-t-il un problème pour des squelettes non Z. Est-il préférable de renommer en ‹ noisetier › ?
Oh oui ! Je trouverais cela de toute façon plus clair et joli 
Ces explications sont-elles suffisamment claires ?
PS : dans le cas du squelette sarka-spip, il existe un répertoire noisettes ce qui peut interférer avec le noizetier. Est considérée comme noisette par le noizetier tout squelette .html accompagné de son .xml situé dans un sous-répertoire noisettes/. Il y a une convention de nommage des noisettes : voir http://www.spip-contrib.net/noiZetier.
Oui je vais le renommer en inclure/. Mais juste un truc, il serait peut etre pas mal de ranger les noisettes dans des sous-rep de noisettes/ non ? Par exemple, pour faire des sortes de bibliotheques et éviter les doublons de nom.
++
Eric
