[SPIP Zone] NoiZetier - quelques évolutions

eric_tonton · Janvier 21, 2017, 4:25

Hello,

En plongeant dans le fonctionnement du NoiZetier je me suis dit qu’on pourrait faire quelques évolutions principalement pour simplifier (de mon point de vue) la configuration des pages et des blocs qui est un peu XML-verbeuse voire redondante.

Si on souhaite utiliser les pages et les blocs sans se préoccuper de leur fournir un libellé explicite, une description, un icone voire d’autres paramètres il est inutile de créer un quelconque fichier XML de configuration. C’est souvent suffisant.

Mais il on veut:

fournir ces paramètres à une page,
définir finement les blocs utilisables pour une pages
décrire les blocs plus lisiblement pour l’interface privée
il est indispensable de créer ces fichiers de configuration XML dont le format est identique à ceux des compositions.
Dans ce cas, si je souhaite préciser pour 2 ou 3 pages sa liste de blocs il va falloir que je décrive autant de fois une balise bloc avec les mêmes attributs de nom, de description voire d’icone.

Aussi je me demande si on ne pourrait pas utiliser uniquement 2 fichiers, plutôt au format YAML (ou alors avec un XML qui soit validé par une DTD), à savoir:

prefixe_pages.yaml
blocs.yaml
et qui contiendraient la configuration de l’ensemble des pages et blocs.
Pour permettre la surcharge ou l’union des pages du path SPIP il faut préfixer le fichier des pages, ce qui n’est pas nécessaire pour les blocs car ceux-ci ne peuvent pas changer pour un squelette donné.
Une alternative serait de ne pas changer l’organisation pour les pages et de laisser un fichier par page.
Pour les compositions on pourrait faire de même mais il faudrait peut-être faire aussi évoluer Compositions.

Qu’en pensez-vous ?

++
Eric

eric_tonton · Janvier 21, 2017, 7:50

On pourrait aussi créer dans chaque répertoire de bloc un fichier YAML ou XML pour décrire le bloc.
Ca serait peut-être la solution la plus simple aujourd’hui qui ne casserait rien non ?

Mist_GraphX · Janvier 24, 2017, 7:04

Le 21/01/2017 à 20:50, Eric Lupinacci a écrit :

On pourrait aussi créer dans chaque répertoire de bloc un fichier YAML
ou XML pour décrire le bloc.
Ca serait peut-être la solution la plus simple aujourd'hui qui ne
casserait rien non ?

Le 21 janvier 2017 à 17:25, Eric Lupinacci <eric@smellup.net
<mailto:eric@smellup.net>> a écrit :

    Hello,

    En plongeant dans le fonctionnement du NoiZetier je me suis dit
    qu'on pourrait faire quelques évolutions principalement pour
    simplifier (de mon point de vue) la configuration des pages et des
    blocs qui est un peu XML-verbeuse voire redondante.

    Si on souhaite utiliser les pages et les blocs sans se préoccuper de
    leur fournir un libellé explicite, une description, un icone voire
    d'autres paramètres il est inutile de créer un quelconque fichier
    XML de configuration. C'est souvent suffisant.

    Mais il on veut:
    - fournir ces paramètres à une page,
    - définir finement les blocs utilisables pour une pages
    - décrire les blocs plus lisiblement pour l'interface privée
    il est indispensable de créer ces fichiers de configuration XML dont
    le format est identique à ceux des compositions.
    Dans ce cas, si je souhaite préciser pour 2 ou 3 pages sa liste de
    blocs il va falloir que je décrive autant de fois une balise bloc
    avec les mêmes attributs de nom, de description voire d'icone.

    Aussi je me demande si on ne pourrait pas utiliser uniquement 2
    fichiers, plutôt au format YAML (ou alors avec un XML qui soit
    validé par une DTD), à savoir:
    - prefixe_pages.yaml
    - blocs.yaml
    et qui contiendraient la configuration de l'ensemble des pages et blocs.
    Pour permettre la surcharge ou l'union des pages du path SPIP il
    faut préfixer le fichier des pages, ce qui n'est pas nécessaire pour
    les blocs car ceux-ci ne peuvent pas changer pour un squelette donné.
    Une alternative serait de ne pas changer l'organisation pour les
    pages et de laisser un fichier par page.
    Pour les compositions on pourrait faire de même mais il faudrait
    peut-être faire aussi évoluer Compositions.

    Qu'en pensez-vous ?

    ++
    Eric

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

Salut Eric,

En fait si on as un skel Z les blocs sont définis par la GLOBAL Z_blocs non ?

si il y'a evo ou refont du Noizettier et composition je serais assez pour que comme Rastapopoulos l'avait suggéré sur un fil de discussion, en profiter pour séparer le core fonctionnel, et l'interface, comme pour champ extra, car on as tous une utilisation différente de ce plugin j'ai l'impression, donc chacun pourrait assembler comme il le souhaite.

--
Bonne journée
Arnaud B. (Mist. GraphX)

eric_tonton · Janvier 24, 2017, 7:51

Hello,

Mist_GraphX · Janvier 24, 2017, 9:39

Ok je vois bien/mieux la problématique.

Effectivement J’avais fait des test sur la dist, donc sans Z : En fait le titre l’icone, titre, description des blocs sont définis en passant par la pipeline noizettier_bloc_defaut


<pipeline nom="noizetier_blocs_defaut" inclure="spipdist_pipelines.php" />

et ensuite :


// Se brancher sur le pipeline du noizetier pour configurer les blocs
// par défaut ou seront ajouté les pre_, post_
// Chaque insertions spécifiques peuvent ensuite êtres réalisé par les compositions de page
// avec par exemple les couples /aside/sommaire.html et /aside/sommaire.xml

function spipdist_noizetier_blocs_defaut($blocs) {
$blocs = array (
'header' => array(
'nom' => _T('noizetier:nom_bloc_header'),
'description' => _T('noizetier:description_bloc_header'),
'icon' => 'bloc-contenu-24.png'
),
'nav' => array(
'nom' => _T('noizetier:nom_bloc_navigation'),
'description' => _T('noizetier:description_bloc_navigation'),
'icon' => 'bloc-navigation-24.png'
),
'footer' => array(
'nom' => _T('noizetier:nom_bloc_footer'),
'description' => _T('noizetier:description_bloc_footer'),
'icon' => 'bloc-extra-24.png'
),
);
return $blocs;
}

De mon coté et dans le même sujet comme on parle de composition (non utilisé conjointement avec le noizettier), il y’a parfois des cas ou une composition devrait necessiter un plugin, comme les noisettes ou menus, c’est pratique dans le cas d’un plugin/librairie de composant et donc le xml :

ceci permettrait de livrer un composition présentant un agenda, depuis un squelette qui utilise seulement agenda, la composition ne serait automatiquement pas listé si le plugin n’est pas activé : je ne crois pas que ce soit le cas actuellement et ça oblige a sélectionner dans la configuration de composition celles que l’on souhaite disponibles.

après autre cas, j’ai eut bien des fois envie de pouvoir ajouter quelques paramètres au compositions : un classe supplémentaire , ne pas afficher un bloc… bref ça impose d’utiliser le noizettier si on veut pouvoir faire ce genre de choses.

donc effectivement, comme tu le suggère il faudrait normaliser/améliorer une structure xml des composants qu’ils soient noisettes, pages, compositions ou blocs.

Bonne journée

Arnaud B. (Mist. GraphX)

triton · Janvier 25, 2017, 9:24

Le 24/01/2017 à 10:39, Arnaud (Mist. GraphX) a écrit :

Ok je vois bien/mieux la problématique.

Effectivement J'avais fait des test sur la dist, donc sans Z : En fait le titre l'icone, titre, description des blocs sont définis en passant par la pipeline noizettier_bloc_defaut

Bonjour,
Chouette, le noizetier évolue, je suis hyper fan de ce plugin depuis le début, je trouve que c est un des points incroyablement forts de spip et que l'on ne retrouve pas dans d'autres cms, la possibilité de créer et de monter par simple administration des nouvelles pages complexes...
Pour l'histoire des blocs et markup j utilise un truc très moche mais qui répond globalement à mes besoins, dans le body.html j ai des inclusions de ce type :
         <div id="#CONFIG{boiteaspip/bloc1}" role="[(#CONFIG{boiteaspip/bloc1}|=={contenu}|oui)contenu][(#CONFIG{boiteaspip/bloc1}|!={contenu}|oui)complementary]"
          class="#CONFIG{boiteaspip/cssbloc1}">
<INCLURE{fond=#CONFIG{boiteaspip/bloc1}/#ENV{type},env}>
         </div>

qui me permettent de configurer par administration les nom id des blocs en fonction des besoins... bien évidement, c est assez moche...
Rendre cela réalisable par administration ou dans un fichier de configuration
Une évolution qui serait très chouette aussi, ca serait la possibilité d'avoir plusieurs "page defaut". Actuellement, sur un site complexe, si on a 20 types de pages différentes, et une seule vraiment différente, on ne peut pas utiliser la page defaut, on est obligé de positionner ses noisettes sur les 19 pages semblables... Sur sharepoint y a un truc qui ressemble au noizetier avec la possibilité d'avoir plusieurs "MasterPage" qui servent de modèles pour créer des nouveaux type de page

et un dernier truc tout bête, mais qui peut s avérer hyper gênant (mais plus a voir avec aveline que noizetier) certaines noisettes forcent le niveau de titre (Hn) de certains éléments, ce qui peut interdire leur utilisation dans certains contextes de page, ca serait bien de systématiquement les rendre configurable. Pour ma part j utilise une astuce toute bête dans les noisettes que je crée : [<(#ENV{niveau_titre})>] blabla [</(#ENV{niveau_titre})>] ou #ENV{niveau_titre} fait partie des éléments configurables par formulaire yaml de la noisette...

amicalement
triton