[SPIP Zone] NoiZetier - Quelques idées d'évlution

Archives Zone
1

Hello,

En intégrant le NoiZetier dans un squelette je me suis dit que certaines évolutions pourraient être envisagées pour améliorer l’expérience utilisateur.
L’utilisation que j’en ai concerne un squelette Z basé sur le framework v2 - donc Z-Core.

Déclaration des pages et blocs:

  • la liste des pages est déterminée par lecture des fichiers XML ou HTML stockés dans le répertoire des contenus principaux des pages (souvent content/). Si on veut modifier cette liste il faut utiliser le pipeline noizetier_lister_pages. Ne pourrait-on pas signifier une liste de pages exclues (constantes, variables globales, fichier?)

  • la liste des blocs est donnée par la variable globale $GLOBALS[‹ z_blocs ›] et cette liste s’applique par défaut à toutes les pages. On peut modifier cette liste de façon globale avec le pipeline noizetier_blocs en particulier pour exclure certains blocs comme head ou head_js. Comme précédemment ne pourrait-on pas signifier par configuration la liste des blocs exclus partout.

  • pour une page donnée on peut décrire dans un fichier XML son titre, sa description et aussi la liste des blocs autorisés si on veut réduire encore plus cette liste pour la page. Et quand on liste les blocs on peut aussi fournir un titre et une description : il n’y a pas d’autre moyen pour cela. Ne pourrait-on pas proposer comme pour les pages une déclaration des blocs.

  • Passer de XML à YAML (y compris pour les compositions)

Déclaration des noisettes:

  • Chaque noisette est définie par un fichier YAML. Il serait intéressant de pouvoir préciser dans ce YAML les pages compatibles ou non plutôt que d’utiliser le nom de la noisette pour cela ce qui ne permet d’ailleurs que de définir 2 valeurs : une page donnée ou toutes les pages.

  • Si cela n’est pas possible ou n’intéresse personne : ne peut-on pas au moins envisager d’autoriser le rangement dans un répertoire sous noisettes/ : noisettes/article/xxxx au lieu de noisettes/article-xxxx

Compilation des noisettes:

  • Chaque noisette est insérée systématiquement dans un div englobant. Pourrait-on débrayer cette fonctionnalité?

  • Chaque noisette est insérée en ajax par défaut. Ne pourrait-on pas inverser le défaut voire configurer le défaut ?

  • Ne pourrait-on pas imaginer le NoiZetier comme un préprocesseur qui produirait les pages HTML avant compilation plutôt qu’après ?

Interface NoiZetier du privé:

  • définir un ordre d’affichage des pages et des blocs

  • Intégrer une noisette dans un bloc donné et l’appliquer en un clic à toutes les pages. Il serait possible ensuite de la retirer de quelques pages si besoin

  • Passer en écran large pour réorganiser l’interface d’ajout des noisettes: par exemple, un onglet par bloc plutôt qu’une litanie de blocs les uns sous les autres

  • présentation plus claire des noisettes avec par exemple un regroupement par plugin fournisseur

  • définir des noisettes favorites pour les avoir mieux positionner dans l’interface

  • renvoyer une erreur quand une noisette à disparue (en général si on renomme le fichier associé)

A votre avis

++

Eric

2

Le 30/01/2017 à 15:38, Eric Lupinacci a écrit :

Si cela n'est pas possible ou n'intéresse personne : ne peut-on pas au
moins envisager d'autoriser le rangement dans un répertoire sous
noisettes/ : noisettes/article/xxxx au lieu de noisettes/article-xxxx

++1 :wink:

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

3

Bonjour,

Le 30/01/2017 à 15:38, Eric Lupinacci a écrit :

En intégrant le NoiZetier dans un squelette je me suis dit que certaines évolutions pourraient être envisagées pour améliorer l'expérience utilisateur.
L'utilisation que j'en ai concerne*un squelette Z basé sur le framework v2 - donc Z-Core*.

Excellente idée, vu que Zpip-dist v1 finit en impasse. Est-ce que ça incluerait la compatibilité SPIPr?

CM

4

Le 30/01/2017 à 15:38, Eric Lupinacci a écrit :

Hello,

En intégrant le NoiZetier dans un squelette je me suis dit que certaines
évolutions pourraient être envisagées pour améliorer l'expérience
utilisateur.
L'utilisation que j'en ai concerne*un squelette Z basé sur le framework
v2 - donc Z-Core*.

_Déclaration des pages et blocs:_

  * la liste des pages est déterminée par lecture des fichiers XML ou
    HTML stockés dans le répertoire des contenus principaux des pages
    (souvent content/). Si on veut modifier cette liste il faut utiliser
    le pipeline noizetier_lister_pages.Ne pourrait-on pas signifier une
    liste de pages exclues (constantes, variables globales, fichier?)
  * la liste des blocs est donnée par la variable
    globale $GLOBALS['z_blocs'] et cette liste s'applique par défaut à
    toutes les pages. On peut modifier cette liste de façon globale avec
    le pipeline noizetier_blocs en particulier pour exclure certains
    blocs comme head ou head_js. Comme précédemment ne pourrait-on pas
    signifier par configuration la liste des blocs exclus partout.
  * pour une page donnée on peut décrire dans un fichier XML son titre,
    sa description et aussi la liste des blocs autorisés si on veut
    réduire encore plus cette liste pour la page. Et quand on liste les
    blocs on peut aussi fournir un titre et une description : il n'y a
    pas d'autre moyen pour cela. Ne pourrait-on pas proposer comme pour
    les pages une déclaration des blocs.
  * Passer de XML à YAML (y compris pour les compositions)

_Déclaration des noisettes:_

  * Chaque noisette est définie par un fichier YAML. Il serait
    intéressant de pouvoir préciser dans ce YAML les pages compatibles
    ou non plutôt que d'utiliser le nom de la noisette pour cela ce qui
    ne permet d'ailleurs que de définir 2 valeurs : une page donnée ou
    toutes les pages.
  * Si cela n'est pas possible ou n'intéresse personne : ne peut-on pas
    au moins envisager d'autoriser le rangement dans un répertoire sous
    noisettes/ : noisettes/article/xxxx au lieu de noisettes/article-xxxx

_Compilation des noisettes:_

  * Chaque noisette est insérée systématiquement dans un div englobant.
    Pourrait-on débrayer cette fonctionnalité?
  * Chaque noisette est insérée en ajax par défaut. Ne pourrait-on pas
    inverser le défaut voire configurer le défaut ?
  * *Ne pourrait-on pas imaginer le NoiZetier comme un préprocesseur qui
    produirait les pages HTML avant compilation plutôt qu'après* ?

_Interface NoiZetier du privé:_

  * définir un ordre d'affichage des pages et des blocs
  * Intégrer une noisette dans un bloc donné et l'appliquer en un clic à
    toutes les pages. Il serait possible ensuite de la retirer de
    quelques pages si besoin
  * Passer en écran large pour réorganiser l'interface d'ajout des
    noisettes: par exemple, un onglet par bloc plutôt qu'une litanie de
    blocs les uns sous les autres
  * présentation plus claire des noisettes avec par exemple un
    regroupement par plugin fournisseur
  * définir des noisettes favorites pour les avoir mieux positionner
    dans l'interface
  * renvoyer une erreur quand une noisette à disparue (en général si on
    renomme le fichier associé)

A votre avis

++

Eric

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

Bonjour,

En fait ça fait pas mal de temps que je regarde ça :

et que je me dit que ça serait le genre d'interface idéale pour le noizettier a intéger. Bon on est sur du javascript et des objets json, mais l'API est très ouverte et propose pas mal de possibilités d'entrée et d'extension a travers des plugins ou connecteurs.

d'ou le fait que si le core fonctionnel du noizettier et l'interface étaient des modules séparés, il pourrait être possible de proposer des systèmes d'interface différents suivant les besoin du squelette final.

Partant du principe que le noizettier peut être intégré partiellement au squelette, et ne proposer la gestion des blocks que sur certaines pages certains blocs. Tout comme il peut comme dans le cas des zpip-vide, spir-vide gérer l'intégralité du squelette.

un idée du matin … comme ça quoi ^^

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

5

Je n’utilise toujours pas Noizettier mais promis je vais m’y mettre.
Je voulais juste faire remarquer, en lisant, que le tout YAML que propose Eric est une bonne chose car on sait bien gérer ça en PHP (pas de souci dans SPIP donc) et que pour l’usage prévu c’est plus simple et moins verbeux que XML…

La proposition d’Arnaud va dans ce sens car on peut aisément convertir en JSON (quoique si on n’a pas le même formalisme c’est plutôt toujours de la transformation mais bon) Après c’est bien les API qui s’appuient sur des messages JSON ; c’est très flexible/adaptable.

Je plussois.

6

Bonjour Eric,

quelques commentaires ci-après

Le lun. 30 janv. 2017 à 15:38, Eric Lupinacci <eric@smellup.net> a écrit :

Hello,

En intégrant le NoiZetier dans un squelette je me suis dit que certaines évolutions pourraient être envisagées pour améliorer l’expérience utilisateur.
L’utilisation que j’en ai concerne un squelette Z basé sur le framework v2 - donc Z-Core.

Déclaration des pages et blocs:

  • la liste des pages est déterminée par lecture des fichiers XML ou HTML stockés dans le répertoire des contenus principaux des pages (souvent content/). Si on veut modifier cette liste il faut utiliser le pipeline noizetier_lister_pages. Ne pourrait-on pas signifier une liste de pages exclues (constantes, variables globales, fichier?)

Je pencherai peut-être pour un fichier du genre « noizetier_config.yaml » dans le répertoire principal dans lequel on pourrait indiquer des éléments de configuration complémentaires. Juste pour avoir tout au même endroit, car sinon cela fait beaucoup de lieux de configuration entre les fichiers du répertoire, les constantes etc. Mais bon, à voir ce qui semble le plus pertinent au final.

  • la liste des blocs est donnée par la variable globale $GLOBALS[‹ z_blocs ›] et cette liste s’applique par défaut à toutes les pages. On peut modifier cette liste de façon globale avec le pipeline noizetier_blocs en particulier pour exclure certains blocs comme head ou head_js. Comme précédemment ne pourrait-on pas signifier par configuration la liste des blocs exclus partout.

Penser à un fichier de configuration global du squelettes (cf. point précédent) ?

  • pour une page donnée on peut décrire dans un fichier XML son titre, sa description et aussi la liste des blocs autorisés si on veut réduire encore plus cette liste pour la page. Et quand on liste les blocs on peut aussi fournir un titre et une description : il n’y a pas d’autre moyen pour cela. Ne pourrait-on pas proposer comme pour les pages une déclaration des blocs.

Une déclaration globale et des possibilités de surcharge page par page ?

  • Passer de XML à YAML (y compris pour les compositions)

Aucun souci pour ma part, mais effectivement, je proposerai qu’on fasse pareil pour le plugin compositions.

Déclaration des noisettes:

  • Chaque noisette est définie par un fichier YAML. Il serait intéressant de pouvoir préciser dans ce YAML les pages compatibles ou non plutôt que d’utiliser le nom de la noisette pour cela ce qui ne permet d’ailleurs que de définir 2 valeurs : une page donnée ou toutes les pages.

Tu as raison

  • Si cela n’est pas possible ou n’intéresse personne : ne peut-on pas au moins envisager d’autoriser le rangement dans un répertoire sous noisettes/ : noisettes/article/xxxx au lieu de noisettes/article-xxxx

Autant carrément passer à ta proposition précédente

Compilation des noisettes:

  • Chaque noisette est insérée systématiquement dans un div englobant. Pourrait-on débrayer cette fonctionnalité?

Oui c’est possible. Une option dans le YAML de config ?

  • Chaque noisette est insérée en ajax par défaut. Ne pourrait-on pas inverser le défaut voire configurer le défaut ?

Configurer le défaut dans le YAML de config ? Comme ça on assure la rétrocompatibilité.

  • Ne pourrait-on pas imaginer le NoiZetier comme un préprocesseur qui produirait les pages HTML avant compilation plutôt qu’après ?

Si tu vois comment faire…

Interface NoiZetier du privé:

  • définir un ordre d’affichage des pages et des blocs
  • Intégrer une noisette dans un bloc donné et l’appliquer en un clic à toutes les pages. Il serait possible ensuite de la retirer de quelques pages si besoin

++

  • Passer en écran large pour réorganiser l’interface d’ajout des noisettes: par exemple, un onglet par bloc plutôt qu’une litanie de blocs les uns sous les autres

a essayer

  • présentation plus claire des noisettes avec par exemple un regroupement par plugin fournisseur

why not

  • définir des noisettes favorites pour les avoir mieux positionner dans l’interface
  • renvoyer une erreur quand une noisette à disparue (en général si on renomme le fichier associé)

++++

A votre avis

++

Eric

Merci à toi Eric de reprendre le noiZetier

Amicalement

Joseph

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

–

–

Joseph LARMARANGE

Demographer PhD at IRD • Ceped (UMR 196 Paris Descartes - IRD)

Tel. (Ceped): +33 1 76 53 34 75

Cell. phone (France) : +33 6 62 06 51 82

Cell. Phone (Côte d’Ivoire): +225 89 40 59 33

Skype: joseph.larmarange
Ceped, 45 rue des Saints-Pères, 75006 Paris, France

7

Le 12/02/2017 à 20:47, Joseph a écrit :

      * présentation plus claire des noisettes avec par exemple un
        regroupement par plugin fournisseur

Moi ya juste ce point là que je ne trouve pas pertinent. Qu'on fasse des groupes de noisettes oui, avec un identifiant de groupe, pouvoir ajouter des groupes etc, mais un découpage automatique par plugins, non. Si un plugin veut mettre toutes ses noisettes à lui dans un même groupe, il pourrait le faire, mais sans automatisme, car un découpage technique n'est pas pareil qu'un découpage sémantique. Parfois ça peut se recouper mais pas obligatoirement.

--
RastaPopoulos

8

Hello,

9

Hello,

Chouette ces propositions d’évolution, mes quelques remarques :

Déclaration des noisettes:

  • Chaque noisette est définie par un fichier YAML. Il serait intéressant de pouvoir préciser dans ce YAML les pages compatibles ou non plutôt que d’utiliser le nom de la noisette pour cela ce qui ne permet d’ailleurs que de définir 2 valeurs : une page donnée ou toutes les pages.

  • Si cela n’est pas possible ou n’intéresse personne : ne peut-on pas au moins envisager d’autoriser le rangement dans un répertoire sous noisettes/ : noisettes/article/xxxx au lieu de noisettes/article-xxxx

Oui, et ça pourrait être une combinaison des 2 :

  • prendre en priorité une entrée « pages » dans le yaml pour définir la liste des pages compatibles
  • sinon se reposer comme maintenant sur le préfixe [type-page]-noisette.html, ou alors en utilisant des sous-dossiers type-page/noisette.html
    Ainsi ça resterait compatible avec les noisettes existantes.

Déclaration des pages et blocs:

  • la liste des pages est déterminée par lecture des fichiers XML ou HTML stockés dans le répertoire des contenus principaux des pages (souvent content/). Si on veut modifier cette liste il faut utiliser le pipeline noizetier_lister_pages. Ne pourrait-on pas signifier une liste de pages exclues (constantes, variables globales, fichier?)
  • la liste des blocs est donnée par la variable globale $GLOBALS[‹ z_blocs ›] et cette liste s’applique par défaut à toutes les pages. On peut modifier cette liste de façon globale avec le pipeline noizetier_blocs en particulier pour exclure certains blocs comme head ou head_js. Comme précédemment ne pourrait-on pas signifier par configuration la liste des blocs exclus partout.

Oui pour ces 2 propositions. Et ce serait pas mal d’unifier aussi non ? Plutôt que de passer un coup par un pipeline, un coup par une globale ?
Peut-être uniquement des pipelines, genre noizetier_lister_pages / noizetier_pages_exclues et noizetier_lister_blocs / noizetier_blocs_exclus ?

pour une page donnée on peut décrire dans un fichier XML son titre, sa description et aussi la liste des blocs autorisés si on veut réduire encore plus cette liste pour la page. Et quand on liste les blocs on peut aussi fournir un titre et une description : il n’y a pas d’autre moyen pour cela. Ne pourrait-on pas proposer comme pour les pages une déclaration des blocs.

Là je ne suis pas sûr de comprendre :slight_smile:
On peut déjà faire tout ce qu’on veut en déclarant les blocs dans le XML non ?

nterface NoiZetier du privé:

  • définir un ordre d’affichage des pages et des blocs

  • Intégrer une noisette dans un bloc donné et l’appliquer en un clic à toutes les pages. Il serait possible ensuite de la retirer de quelques pages si besoin

  • Passer en écran large pour réorganiser l’interface d’ajout des noisettes: par exemple, un onglet par bloc plutôt qu’une litanie de blocs les uns sous les autres

  • présentation plus claire des noisettes avec par exemple un regroupement par plugin fournisseur

  • définir des noisettes favorites pour les avoir mieux positionner dans l’interface

  • renvoyer une erreur quand une noisette à disparue (en général si on renomme le fichier associé)

Et je rajouterais :

  • Enregistrement immédiat quand on dépose une noisette dans un bloc, ou qu’on les réordonne par glisser-déposer (pas besoin du message de confirmation)
  • Pas besoin de message « Ce bloc ne contient pas de noisette. »

Ensuite, j’ai 2 remarques supplémentaires :

groupe de noisettes

Sur un projet assez gros, le contenu des pages reposait presque entièrement sur des noisettes.
Il y a un point qui nous a posé problème, c’est qu’on ne peut pas faire de groupe de noisettes.
Impossible en l’état de gérer le colonnage en front, puisque toutes les noisettes se mettent les unes à la suite des autres, il manque la notion de noisette « conteneur ».
On s’en est sortis en faisant 2 noisettes « ouverture/fermeture d’un groupe de noiettes », qui ne servent qu’à ouvrir et fermer un

. Mais c’est du bricolage, idéalement il faudrait pouvoir mettre des noisettes « dans » une noisette type conteneur.

édition des noisettes d’un objet

RastaPopoulos a ajouté la possibilité de définir les noisettes pour un objet précis.
Du coup je pense qu’il faut répercuter ça un peu mieux dans l’interface. Pour l’instant, ça ajoute un lien « N noisettes configurées » dans la boîte d’infos de l’objet qui mène vers la page de configuration des noisettes.
Mais je pense qu’il faut qu’on ait directement un aperçu du contenu des noisettes dans la page de l’objet.
Aucune raison de devoir se rendre sur une autre page pour éditer des noisettes qui ne vont concerner qu’un objet précis.

Glop

10

Hello,

11

Hello,

Suite des idées sur le noiZetier.
Je creuse je code, je modifie petit à petit le code pour intégrer les idées discutées mais je trouve quand même que c’est bien compliqué et que trainer les squelettes non-Z, le Z v1 et le Z v2 avec Zcore amène une complexité importante.
Alors je me pose une question de l’utilité de cette compatibilité.

Ne pourrait-on pas imaginer dans cette version 3.0.0 du noiZetier de se concentrer uniquement sur les squelettes Z v2 avec Zcore ?

12

Le 04/03/2017 à 13:31, Eric Lupinacci a écrit :

Hello,

Suite des idées sur le noiZetier.
Je creuse je code, je modifie petit à petit le code pour intégrer les
idées discutées mais je trouve quand même que c'est bien compliqué et
que trainer les squelettes non-Z, le Z v1 et le Z v2 avec Zcore amène
une complexité importante.
Alors je me pose une question de l'utilité de cette compatibilité.

Ne pourrait-on pas imaginer dans cette version 3.0.0 du noiZetier de se
concentrer uniquement sur les squelettes Z v2 avec Zcore ?

Je m'immisce un chouilla : ne conserver que la compatibilité z-core (avec les z-blocs donc) me paraît le plus pertinent (z1 et z2 je pense qu'on peut oublier).

Par contre, c'est quoi la compatibilité "non-Z" ?

Et enfin qu'entends-tu par Zcore également ? est-ce que ça prend en compte automatiquement en utilisant la déclaration z-blocs (qui peut être modifiée), ou est-ce que c'est arbitrairement utiliser la déclaration z-blocs de spipr (content/ ...) ?

C'est peut être des questions de néophyte qui n'a pas suivi les discussions :slight_smile:

MM.

13

Yop,

14

Moi je ne vois pas pourquoi ça devrait être limité à Z, même si moi-même je n'utilise que z-core depuis des années.

Le noizetier c'est juste une sorte de "compilateur de blocs" (je parle des noisettes pas des blocs de Z) qu'on configure et qu'on met dans un certain ordre. Le fait qu'ensuite ça s'insère à tels ou tels endroits des pages c'est une *deuxième* étape, et on peut très bien vouloir insérer ces blocs n'importe où, dans des endroits qu'on décide. D'où le fait d'ailleurs, pour y voir plus clair, que moi je vois une distinction très net dans le code entre l'aspect "description-configuration-compilation", et l'aspect "on garde ça en mémoire de telle manière et on le lie à tels endroits des pages de telle manière et on l'insère dans les pages à ces endroits".

--
RastaPopoulos

15

Le 4 mars 2017 à 14:18, RastaPopoulos <rastapopoulos@spip.org> a écrit :

Moi je ne vois pas pourquoi ça devrait être limité à Z, même si moi-même
je n'utilise que z-core depuis des années.

Ben d'une part parce que je pense que c'est rarement utilisé (voir pas du
tout) et que ça complexifie le code inutilement. En plus certaines
fonctions ne sont pas disponibles comme l'edition en public.
Après, c'est exact que ce qui est le plus inutilement complexe dans le
noizetier c'est le support de Z v1 avec des blocs prédéfinis et des pages
qui s'appellent page-xxxx.
Ca franchement il faudrait s'en affranchir.

Après il y a des paramètres que je trouve compliqués:

_NOIZETIER_REPERTOIRE_PAGES : dossier relatif où trouver les pages. Le
supprimer et choisir automatiquement le z-blocs [0] ou alors la racine si
non Z serait plus simple.

_NOIZETIER_LISTER_PAGES_SANS_XML : autorise de rechercher les pages qui
n’ont pas de description XML ou YAML. Je pense qu'il faudrait carrément
supprimer ce paramètre.

_NOIZETIER_RECUPERER_FOND : active ou désactive l’insertion automatique
des noisettes au travers du pipeline recuperer_fond. Utile uniquement pour
les squelettes non Z.

_NOIZETIER_COMPOSITIONS_TYPE_PAGE : je ne vois pas à quoi ça sert mais ça
semble utile uniquement que pour Z v1 non?

Donc je serais d'avis de nettoyer un peu tout ça pour justement arriver
plus facilement au résultat que tu souhaiterais.

16

Le 04/03/2017 à 14:44, Eric Lupinacci a écrit :

Donc je serais d'avis de nettoyer un peu tout ça pour justement arriver
plus facilement au résultat que tu souhaiterais.

Ouais par contre gérer les spécificités de Z1 dans le noizetier, ça oui je pense que ça peut être viré.

--
RastaPopoulos

17

Hello,

En plus certaines fonctions ne sont pas disponibles comme l’edition en public.

si, c’est géré il suffit de mettre/surcharger le squelette adéquat, par exemple sur une dist de spip :

noizettier-generer.html

un exemple ici
https://github.com/mistergraphx/spip_dist_noizettier

ayant déjà jeté un œil sur le code du noizettier je ne sais pas si c’est en enlevant des compatibilités ou fonctionnalités,
qu’on va rendre le code plus lisible ou simple (ou alors faut en enlever un paquet) ^^
Pour Zv1 clair que ça n’as pas vraiment d’intérêt.

De mon humble avis, je reste sur l’idée que ce plugin gagnerait â être découpé, voir a passer en classes le noyaux fonctionnel (la ce serait lisible et clair).
Et idéalement si l’interface faisait le calcul coté client en local storage et envoyer le résultat final, ça serait bien :
la on a un hit a chaque déplacement de noizette, avec un connexion pas terrible sur un hébergement moyen ça plante, et on perd tout (parfois même la page complète à reconfigurer).

​