Par contre, et là peut-être que l'on va tomber sur un autre désaccord, une
grappe est toujours composé d'un squelette et éventuellement d'autres
choses.
[…]
C'est là où je pense qu'on diverge maintenant.
Je pense que la "Grappe" identifie toujours à minima un squelette (pour
la compilation). Si cela n'est pas le cas, il faudrait une autre
indirection qui préciserait : telle grappe je la met dans telle
squelette. Là je ne vois pas l'intérêt.
Oui c'est bien ça la divergence, mais la liaison ne parait problématique
que si on part du principe que ça doit être lié. Moi je pars du principe
que tout n'a pas le même sens et la même utilisation que le noizetier
public et que donc non, on n'a pas forcément à lier telle contexte à tel
squelette.
Pour moi ce stockage ne faut que pour le Noizetier qui construit des
pages publiques, pas pour d'autres utilisations où l'appel à "la liste
des noisettes de tel cas/tel contexte" n'a pas du tout de lien
obligatoire avec un squelette.
Pour le Dashboard, chaque tableau de bord est celui d'un utilisateur,
point. Il n'y a pas spécialement de raison de le stocker ailleurs que
dans la table spip_auteurs, dans un champ dédié, dans un tableau
sérialisé. En ayant pour cela une norme unique décrivant une "liste de
noisettes" dans un tableau PHP, comme Saisies.
Ensuite le plugin va surcharger l'accueil (ou pas, ça peut être dans une
autre page), va récupérer le bon tableau de bord, et va faire en gros
<INCLURE{fond=inclure/noisettes_afficher, zone=content,
noisettes=#LE_TABLEAU}>
Je n'en ai pas parlé il me semble précédemment, mais c'est d'ailleurs
une des utilisations *déjà* actuelles parfois. Nous on en a beaucoup eu
besoin avec justement les "noisettes par objet", pas du tout en
utilisant Z-core et ses blocs-zones. Car on a fait des expositions
virtuelles qui ont des chapitres, des sous-chapitres, etc, et donc
c'était des rubriques et sous-rubriques, avec dans chacune des noisettes
pour ce chapitre. Et à la fin il n'y avait QU'UN unique squelette, celui
de la composition de la branche racine de l'exposition, et NOUS-MÊMES
dedans, on faisait les boucles de rubrique, et on intégrait le <INCLURE>
pour les noisettes de chaque rubrique (pour le bloc "content"
uniquement, on utilisait que ça).
C'est une utilisation hors Z, hors insertion automatique dans les
squelettes avec recuperer_fond, et c'est très récent, sur un SPIP 3.1,
et c'est indispensable de pouvoir continuer de faire ce genre de choses.
Le stockage des associations se fait donc sur la base du couple
(squelette, contexte) ce qui autorise toutes les libertés.
Ça a l'air vraiment bien et générique, je n'en doute pas du tout, et
peut-être même pas spécialement compliqué à utiliser.
Mais je vais redire la conversation pour IRC pour pas perdre : en
commençant à comprendre la direction dans laquelle ça va pour le moment,
et bien je me suis dit que ça me faisait penser à un état d'esprit
informaticien qui se dit "ah j'ai trouvé une super structure
über-générique" et qui ensuite essaye de faire tout rentrer dedans (ça
marche on peut le faire donc faut le faire).
À la base, quand j'imagine le noyau des noisettes, je ne vois pas de
stockage du tout, fut-il par défaut et optionnel. Aucune installation de
table (car ça peut parfaitement être autre part que des tables) :
uniquement une API (et si possible une interface mais dans un deuxième
temps).
Je le redis, mais pour moi c'est vraiment le même principe que Saisies :
- on doit pouvoir lister les types disponibles et leurs options
- on doit pouvoir générer du HTML à partir d'une description de noisette
(un type + un contexte correspondant aux options)
- on doit pouvoir générer du HTML à partir d'une LISTE de noisettes
(génération en masse de tout à partir d'une unique description commune)
Et donc pour ça utiliser le même principe d'un tableau qui décrit toute
la liste. Cela permet que ça vienne de n'importe où, d'une base ou d'une
génération à la volée autrement peu importe. Et ça permet beaucoup plus
facilement d'avoir alors des noisettes "conteneur" à l'infini, sans
jamais avoir à gérer de "id_parent" ou autre merde dans le genre (cf la
galère sur le stockage de Menus).
Par ailleurs, dans une même description, on peut parfaitement séparer et
avoir ensemble directement les différentes "zones". À la fin on a donc
UN unique tableau, qu'on peut stocker en une fois comme on veut, et
récupérer en une seule fois pareil, pour l'envoyer au squelette de
génération.
À aucun moment, même dans le Noizetier, on a besoin de récupérer UNE
noisette unique (une implémentation de noisette), en SQL, au niveau
utilisation finale, jamais. (C'est le cas pour l'interface de création,
qui permet dans une page séparée de configurer telle noisette ajoutée,
mais ça s'est fait dans l'autre sens, parce que justement c'était
stockée dans une ligne à part.)
array(
'content' => array(
array(
'type' => 'noisettes/texte',
'options' => array('option1'=>'oui', etc),
),
array(
'type' => 'noisettes/strate',
'options' => array('option1'=>'oui', etc),
'noisettes' => array(
// des noisettes enfants !
),
),
),
'aside' => array(
…
),
)
Du coup il y a tout ce qu'il faut dedans. Dans Formidable ça permet de
stocker les formulaires complets dans UNE ligne : une par formulaire. À
aucun moment on a besoin de récupérer une saisie unique dans la base, on
veut toujours le formulaire complet.
Pour Menus c'est pareil, ça fait des années que dans ma todolist ya de
changer pour un tableau comme ça, et de stocker chaque menu dans UNE
ligne SQL par menu, car on veut toujours toute la description d'un menu
à la fois, jamais d'une entrée seulement.
Là pour les noisettes, ça permettrait pour le Noizetier, d'avoir une
ligne par contexte : (squelette=article | composition=truc |
noisettes=tableau complet) ou (objet=rubrique | id_objet=1234 |
noisettes=tableau complet)
Et pour d'autres utilisations ce tableau serait stocké ailleurs, pour le
Dashboard dans un unique champ "dashboard" de spip_auteurs par exemple :
strictement aucun besoin de stockage complexe avec plein de champs.
Bon… réveil dans 5h30 maintenant, peut-être dormir 
--
RastaPopoulos