[SPIP Zone] [Spip-zone-commit] r35083 - in _plugins_/noiZetier: . noiZetier-2_0 noiZetier-2_0/action noiZetier-2_0/balise noiZetier-2_0/base noiZetier-2_0/css noiZetier-2_0/formulaires noiZetier-2_0/img noiZetier-2_0/inc noiZetier-2_0/inclure noi

Archives Zone
1

heu… oué …
je commit mon truc aussi comme ça on aura 3 noisetiers sur la zone ? …
Peut-être qu’avant de coder tête baissée et de partir dans tous les
sens on peut prendre le temps de réflechir, discuter, et se mettre
d’accord (faire de la conception quoi) ?

Depuis quand on critique quelqu’un qui pose des briques sur la zone
S’il les pose c’est dans l’optique d’un travail collaboratif
Comment Joseph pouvait t-il deviner que Cedric avait un proto caché de noizettes ?

Bref.
Tout ça pour dire que dans un projet collaboratif, c’est pas mal de
discuter avant de partir tout seul dans sa direction :stuck_out_tongue:

C’est pas mal d’en discuter aussi une fois que les trucs sont posés
Sans quoi il n’y a pas de discussion possible
Joseph n’a jamais refusé le dialogue que je sache !

Alexandra qui dit non à la dictacture ^^

2010/2/11 <joseph@larmarange.net>:

Author: joseph@larmarange.net
Date: 2010-02-11 10:12:26 +0100 (Thu, 11 Feb 2010)
New Revision: 35083

Added:
plugins/noiZetier/noiZetier-2_0/
plugins/noiZetier/noiZetier-2_0/action/
plugins/noiZetier/noiZetier-2_0/action/activer_page_noizetier.php
plugins/noiZetier/noiZetier-2_0/action/desactiver_page_noizetier.php
plugins/noiZetier/noiZetier-2_0/action/supprimer_noisettes_page_noizetier.php
plugins/noiZetier/noiZetier-2_0/balise/
plugins/noiZetier/noiZetier-2_0/balise/noizetier_liste_pages.php
plugins/noiZetier/noiZetier-2_0/base/
plugins/noiZetier/noiZetier-2_0/base/noizetier_installation.php
plugins/noiZetier/noiZetier-2_0/base/noizetier_tables.php
plugins/noiZetier/noiZetier-2_0/css/
plugins/noiZetier/noiZetier-2_0/css/noizetier.css
plugins/noiZetier/noiZetier-2_0/fonds/
plugins/noiZetier/noiZetier-2_0/formulaires/
plugins/noiZetier/noiZetier-2_0/formulaires/configurer_bloc.html
plugins/noiZetier/noiZetier-2_0/formulaires/configurer_bloc.php
plugins/noiZetier/noiZetier-2_0/formulaires/inc-configurer-noisettes.html
plugins/noiZetier/noiZetier-2_0/formulaires/inc-nouvelle_noisette-1.html
plugins/noiZetier/noiZetier-2_0/formulaires/inc-nouvelle_noisette-2.html
plugins/noiZetier/noiZetier-2_0/img/
plugins/noiZetier/noiZetier-2_0/img/compositions-24.png
plugins/noiZetier/noiZetier-2_0/img/export.png
plugins/noiZetier/noiZetier-2_0/img/ic_accueil.png
plugins/noiZetier/noiZetier-2_0/img/ic_ariane.png
plugins/noiZetier/noiZetier-2_0/img/ic_article.png
plugins/noiZetier/noiZetier-2_0/img/ic_auteur.png
plugins/noiZetier/noiZetier-2_0/img/ic_bloctexte.png
plugins/noiZetier/noiZetier-2_0/img/ic_boussole.png
plugins/noiZetier/noiZetier-2_0/img/ic_breve.png
plugins/noiZetier/noiZetier-2_0/img/ic_configuration.png
plugins/noiZetier/noiZetier-2_0/img/ic_documents.png
plugins/noiZetier/noiZetier-2_0/img/ic_forum.png
plugins/noiZetier/noiZetier-2_0/img/ic_logosite.png
plugins/noiZetier/noiZetier-2_0/img/ic_mot.png
plugins/noiZetier/noiZetier-2_0/img/ic_pagedefaut.png
plugins/noiZetier/noiZetier-2_0/img/ic_petition.png
plugins/noiZetier/noiZetier-2_0/img/ic_portfolio.png
plugins/noiZetier/noiZetier-2_0/img/ic_recherche.png
plugins/noiZetier/noiZetier-2_0/img/ic_rubrique.png
plugins/noiZetier/noiZetier-2_0/img/ic_site.png
plugins/noiZetier/noiZetier-2_0/img/import.png
plugins/noiZetier/noiZetier-2_0/img/noizetier-16.png
plugins/noiZetier/noiZetier-2_0/img/noizetier-24.png
plugins/noiZetier/noiZetier-2_0/img/noizetier-48.png
plugins/noiZetier/noiZetier-2_0/img/noizetier_action_ajouter.png
plugins/noiZetier/noiZetier-2_0/img/noizetier_action_bas.png
plugins/noiZetier/noiZetier-2_0/img/noizetier_action_haut.png
plugins/noiZetier/noiZetier-2_0/img/noizetier_action_modifier.png
plugins/noiZetier/noiZetier-2_0/img/noizetier_action_supprimer.png
plugins/noiZetier/noiZetier-2_0/inc/
plugins/noiZetier/noiZetier-2_0/inc/noizetier.php
plugins/noiZetier/noiZetier-2_0/inclure/
plugins/noiZetier/noiZetier-2_0/inclure/noizetier-documents.html
plugins/noiZetier/noiZetier-2_0/inclure/noizetier-portfolio.html
plugins/noiZetier/noiZetier-2_0/lang/
plugins/noiZetier/noiZetier-2_0/lang/noizetier_fr.php
plugins/noiZetier/noiZetier-2_0/noisettes/
plugins/noiZetier/noiZetier-2_0/noisettes/article-contenuprincipal.html
plugins/noiZetier/noiZetier-2_0/noisettes/article-contenuprincipal.xml
plugins/noiZetier/noiZetier-2_0/noisettes/article-documents.html
plugins/noiZetier/noiZetier-2_0/noisettes/article-documents.xml
plugins/noiZetier/noiZetier-2_0/noisettes/article-filariane.html
plugins/noiZetier/noiZetier-2_0/noisettes/article-filariane.xml
plugins/noiZetier/noiZetier-2_0/noisettes/article-forum.html
plugins/noiZetier/noiZetier-2_0/noisettes/article-forum.xml
plugins/noiZetier/noiZetier-2_0/noisettes/article-petition.html
plugins/noiZetier/noiZetier-2_0/noisettes/article-petition.xml
plugins/noiZetier/noiZetier-2_0/noisettes/article-portfoliosimple.html
plugins/noiZetier/noiZetier-2_0/noisettes/article-portfoliosimple.xml
plugins/noiZetier/noiZetier-2_0/noisettes/page-bloctexte.html
plugins/noiZetier/noiZetier-2_0/noisettes/page-bloctexte.xml
plugins/noiZetier/noiZetier-2_0/noisettes/page-logositespip.html
plugins/noiZetier/noiZetier-2_0/noisettes/page-logositespip.xml
plugins/noiZetier/noiZetier-2_0/noisettes/rubrique-contenuprincipal.html
plugins/noiZetier/noiZetier-2_0/noisettes/rubrique-contenuprincipal.xml
plugins/noiZetier/noiZetier-2_0/noizetier/
plugins/noiZetier/noiZetier-2_0/noizetier/noizetier-pages.xml
plugins/noiZetier/noiZetier-2_0/noizetier_autoriser.php
plugins/noiZetier/noiZetier-2_0/noizetier_fonctions.php
plugins/noiZetier/noiZetier-2_0/noizetier_options.php
plugins/noiZetier/noiZetier-2_0/noizetier_pipelines.php
plugins/noiZetier/noiZetier-2_0/plugin.xml
plugins/noiZetier/noiZetier-2_0/prive/
plugins/noiZetier/noiZetier-2_0/prive/exec/
plugins/noiZetier/noiZetier-2_0/prive/exec/configurer_page.html
plugins/noiZetier/noiZetier-2_0/prive/exec/noizetier.html
plugins/noiZetier/noiZetier-agenda/
plugins/noiZetier/noiZetier-agenda/lang/
plugins/noiZetier/noiZetier-agenda/lang/noizetier-agenda_fr.php
plugins/noiZetier/noiZetier-agenda/noizetier/
plugins/noiZetier/noiZetier-agenda/noizetier/noizetier-agenda-pages.xml
plugins/noiZetier/noiZetier-agenda/plugin.xml
Log:
Dépôt du plugin noiZetier (version en cours de développement)

Details: http://zone.spip.org/trac/spip-zone/changeset/35083

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

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

2

Oui,
Cédric a écrit :

    Tout ça pour dire que dans un projet collaboratif, c'est pas mal de
    discuter avant de partir tout seul dans sa direction :stuck_out_tongue:

C'est universel et donc surement réflexif !

D'ailleurs, "partir tout seul", ça commence pas avec un commit sur la zone,
mais plutôt avec l'écriture de code.

Et même, pour qu'un projet soit non seulement collaboratif mais "ouvert",
il faudrait documenter la discussion !

JLuc

3

2010/2/12 Alexandra Guiderdoni <alexandra.guiderdoni@gmail.com>:

heu... oué ...
je commit mon truc aussi comme ça on aura 3 noisetiers sur la zone ? ...
Peut-être qu'avant de coder tête baissée et de partir dans tous les
sens on peut prendre le temps de réflechir, discuter, et se mettre
d'accord (faire de la conception quoi) ?

Depuis quand on critique quelqu'un qui pose des briques sur la zone
S'il les pose c'est dans l'optique d'un travail collaboratif
Comment Joseph pouvait t-il deviner que Cedric avait un proto caché de
noizettes ?

Bref.
Tout ça pour dire que dans un projet collaboratif, c'est pas mal de
discuter avant de partir tout seul dans sa direction :stuck_out_tongue:

C'est pas mal d'en discuter aussi une fois que les trucs sont posés

Justement. J'ai posé Zpip, joseph a posé un noisetier y a deux an
déja. Peut être que discuter de comment, quoi, pourquoi ... etc avant
de refaire le coup du nouveau noisetier (on fait quoi de l'ancien déjà
sur la zone ?) amènerait une solution plus pérenne que se retrouver
avec 36 versions et fork.

En l'occurence, je note que déjà les objectifs de Joseph ne sont pas
les mêmes que les miens, où il veut que TOUT soit noisetisable alors
que pour moi le squelette doit tout de même fournir une ossature avec
un minimum de contenu, et un noisetier permettrait d'enrichir et
personnaliser.

Sans quoi il n'y a pas de discussion possible
Joseph n'a jamais refusé le dialogue que je sache !

Alexandra qui dit non à la dictacture ^^

Surement.

4

Le 12 février 2010 11:28, JLuc <jluc@no-log.org> a écrit :

Oui,
Cédric a écrit :

Tout ça pour dire que dans un projet collaboratif, c'est pas mal de
discuter avant de partir tout seul dans sa direction :stuck_out_tongue:

C'est universel et donc surement réflexif !

surement oui.

D'ailleurs, "partir tout seul", ça commence pas avec un commit sur la zone,
mais plutôt avec l'écriture de code.

Avec l'idée même.

Et même, pour qu'un projet soit non seulement collaboratif mais "ouvert",
il faudrait documenter la discussion !

Discussion ouverte et documentée il y a 15 mois, après une
présentation publique des principes a bruxelles, qui a fait l'objet
d'un enregistrement audio retranscrit.
Article qui n'a pas fait l'objet d'une frénésie ni d'un engouement remarquable.

Puis relancée la, après 12 mois de maturation, et des quelques retours
de ceux qui ont creusés un peu plus, une expérimentation par d'autres
contributeurs etc ..

puis les publis suivantes qui constituent une documentation de Zpip.
Cédric

5

Le 12/02/2010 11:05, Cédric Morin a écrit :

Justement. J'ai posé Zpip, joseph a posé un noisetier y a deux an
déja. Peut être que discuter de comment, quoi, pourquoi ... etc avant
de refaire le coup du nouveau noisetier (on fait quoi de l'ancien déjà
sur la zone ?) amènerait une solution plus pérenne que se retrouver
avec 36 versions et fork.

Concernant le projet "noisetier" historique, je l'ai pour ma part complètement abandonné : trop ambitieux, pas adapté avec toutes les évolutions qu'a connu SPIP etc.

Dès lors, il mériterait de passer aux archives comme simple état d'une réflexion à un moment donnée (sur la zone, je ne sais pas si la politique serait de le supprimer ou si un répertoire archivage est prévu).

En l'occurence, je note que déjà les objectifs de Joseph ne sont pas
les mêmes que les miens, où il veut que TOUT soit noisetisable alors
que pour moi le squelette doit tout de même fournir une ossature avec
un minimum de contenu, et un noisetier permettrait d'enrichir et
personnaliser.

Effectivement, pour moi tout doit pouvoir être noisetisable pour la bonne et simple raison qu'en général la première chose que je suis amené à modifier sur un squelette c'est le contenu par défaut de certaines pages. Donc je veux garder la possibilité de modifier ce contenu par défaut (voir de le supprimer par exemple avec une page auteur quand la notion d'auteur n'est pas pertinente sur un site particulier).

Cela ne signifie pas pour moi qu'il ne faut pas fournir à l'utilisateur un contenu prêt à l'emploi pour que son site puisse fonctionner de suite.

Cela passe par deux éléments (à discuter) dans ma réflexion : la possibilité d'activer ou de désactiver le noizetier sur chaque page. Autrement dit, tant que le noizetier n'est pas activé sur une page, c'est les contenus par défaut de Zpip (ou surcharges dans squelettes) qui sont affichés.
Par ailleurs, la possibilité de fournir des configuration de noisettes prêtes à l'emploi (contenus par défaut de Zpip, configuration type blog, etc.), que l'on peut installer au choix et personnaliser ensuite (et même exporter sa propre configuration).

Suites possibles pour le noiZetier :

1/ On le retire purement et simplement de la zone. Ca restera simplement un protype que j'aurais écrit pour moi et qui m'aura permis de tester quelques idées.

2/ Je termine de le documenter et le complète un peu pour qu'il soit fonctionnel. Il sert alors simplement d'éléments de discussion sur ce que pourrait être un futur noisetier/noyer/gestionnaire de noisettes (peu importe le nom) et on ouvre une page wiki pour que chacun puisse apporter ses points de vue sur différents aspects :
- qu'est ce qui est noisetable ou pas ?
- notion d'activation/désactivation sur une page pertinente ou non ?
- nommage des noisettes et précision sur où elles peuvent être proposées (toutes les pages, juste certaines, lesquelles, certains blocs...)
- éléments nécessaires/optionnels pour décrire une noisette (nom, description, icônes, blocs, etc.)
- interface de gestion des noisettes (compréhensible, obscure, à simplifier, optimiser...)
- faut-il mieux utiliser xml ou yaml pour décrire les noisettes ? (débat pour le coup plus général puisque les menus et les compositions sont décrits en xml, les saisies en xml mais si j'ai bien compris sont en train de migrer en une description yaml)
- comment défini-t-on les pages sont gérables à un gestionnaire de noisettes ?
- quelles icônes utiliser ? que faut-il uniformiser ? Faut-il utiliser un set d'icônes communes à plusieurs plugins afin d'améliorer l'interface utilisateur ?
- interactions entre les compositions et le gestionnaire de noisettes
- interactions entre plugins et Zpip et gestionnaire de noisettes
- nouvelles saisies à développer
- recourir ou non à des modèles pour afficher les liste d'objets

Tout ce que j'ai pu oublié dans la présente liste...

Au delà des personnes qui développent, avoir des retours d'utilisateurs qui ne touchent pas au code peut être intéressant.

De là, soit ça fait avancer le Schmilblick, que cela aboutisse à modifier le noizetier ou à développer un autre plugin tout neuf tout propre, alors tant mieux. => solution 2

Soit une majorité pense que c'est inutile, que ça fout la merde plus qu'autre chose et que c'est contre-production. => solution 1

Soit certains ont d'autres approches à proposer. Je serai ravi d'en discuter.

Bien cordialement

Joseph

6

Alors moi je réponds à Cédric en argumentant des choses et en faisant quelques propositions, mais tout le monde s'en fout.

Par contre quand on écrit pour troller sur le ton employé, là ça y va, ça discute !...

--
RastaPopoulos, va forker Drupal dans son coin.

7

Le 12 févr. 2010 à 12:54, Joseph a écrit :

Le 12/02/2010 11:05, Cédric Morin a écrit :

Justement. J'ai posé Zpip, joseph a posé un noisetier y a deux an
déja. Peut être que discuter de comment, quoi, pourquoi ... etc avant
de refaire le coup du nouveau noisetier (on fait quoi de l'ancien déjà
sur la zone ?) amènerait une solution plus pérenne que se retrouver
avec 36 versions et fork.

Concernant le projet "noisetier" historique, je l'ai pour ma part complètement abandonné : trop ambitieux, pas adapté avec toutes les évolutions qu'a connu SPIP etc.

Dès lors, il mériterait de passer aux archives comme simple état d'une réflexion à un moment donnée (sur la zone, je ne sais pas si la politique serait de le supprimer ou si un répertoire archivage est prévu).

Il faudrait le ranger alors. Soit le déplacer dans _fondation_/ sur la zone si tu penses que le garder sous la main peut être utile, soit le supprimer complètement (sachant qu'il est toujours retrouvable avec svn) sinon.

En l'occurence, je note que déjà les objectifs de Joseph ne sont pas
les mêmes que les miens, où il veut que TOUT soit noisetisable alors
que pour moi le squelette doit tout de même fournir une ossature avec
un minimum de contenu, et un noisetier permettrait d'enrichir et
personnaliser.

Effectivement, pour moi tout doit pouvoir être noisetisable pour la bonne et simple raison qu'en général la première chose que je suis amené à modifier sur un squelette c'est le contenu par défaut de certaines pages. Donc je veux garder la possibilité de modifier ce contenu par défaut (voir de le supprimer par exemple avec une page auteur quand la notion d'auteur n'est pas pertinente sur un site particulier).

Cela ne signifie pas pour moi qu'il ne faut pas fournir à l'utilisateur un contenu prêt à l'emploi pour que son site puisse fonctionner de suite.

Cela passe par deux éléments (à discuter) dans ma réflexion : la possibilité d'activer ou de désactiver le noizetier sur chaque page. Autrement dit, tant que le noizetier n'est pas activé sur une page, c'est les contenus par défaut de Zpip (ou surcharges dans squelettes) qui sont affichés.

Je ne souscris pas à cette approche. Un gestionnaire de noisette doit servir à enrichir des pages. Le fait d'utiliser un tel gestionnaire pour court-circuiter des squelettes ou desactiver des pages me paraît contre-intuitif, et une mauvaise approche.
Tel que je le vois après avoir pris en compte les besoins que tu exprimes :

- le gestionnaire de noisettes permet de gérer tous les types de page, compositions comprises, en ajoutant des noisettes (ou en déplaçant/modifiant celles que le squelette a pu pré-configurer)
- le gestionnaire de noisettes ne court-circuite aucun squelette : il ajoute juste aux squelettes comme contenu/article, extra/article, navigation/article le contenu des noisettes demandées
- ainsi, un concepteur de squelette peut choisir de mettre certains contenus en "dur" dans les squelette ou compositions, et d'autre sous forme de noisettes avec une pré-configuration par défaut (une liste des noisettes pour chaque page et chaque bloc)

- ceux qui veulent, comme toi, pouvoir tout gérer par le gestionnaire de noisettes peuvent prévoir une squelette Z où tout est en noisettes et modifiable, donc. Avec une configuration comme tu le propose ci-dessous.

- d'autres projets auront des degrés de libertés moins forts, en choisissant d'avoir toujours un contenu non debrayable
Typiquement, il me parait assez bancal et dangereux de fournir un contenu/article vide sauf à risquer que le webmestre y mette n'importe quoi, y compris du contenu qui n'a rien à voir avec un article. Mais c'est juste mon avis que je ne veux pas imposer.

Par ailleurs, la possibilité de fournir des configuration de noisettes prêtes à l'emploi (contenus par défaut de Zpip, configuration type blog, etc.), que l'on peut installer au choix et personnaliser ensuite (et même exporter sa propre configuration).

Suites possibles pour le noiZetier :

1/ On le retire purement et simplement de la zone. Ca restera simplement un protype que j'aurais écrit pour moi et qui m'aura permis de tester quelques idées.

2/ Je termine de le documenter et le complète un peu pour qu'il soit fonctionnel. Il sert alors simplement d'éléments de discussion sur ce que pourrait être un futur noisetier/noyer/gestionnaire de noisettes (peu importe le nom) et on ouvre une page wiki pour que chacun puisse apporter ses points de vue sur différents aspects :
- qu'est ce qui est noisetable ou pas ?
- notion d'activation/désactivation sur une page pertinente ou non ?

Ton besoin de by-passer/bloquer des pages (comme la page auteur par exemple) est un autre besoin que tu peux déjà remplir dans un plugin séparé, et qui consiste simplement à s'insérer dans le pipeline styliser et bloquer l'acces aux squelettes concernés en les ré-aiguillant vers la page 404.

Il semble juste que le noisetier devra proposer un pipeline pour lister les pages disponibles, ce qui permettra aux autres plugins d'ajouter ou supprimer des pages configurables (ça n'a pas de sens de laisser configurable une page qui a été bloquée par ailleurs).

- nommage des noisettes et précision sur où elles peuvent être proposées (toutes les pages, juste certaines, lesquelles, certains blocs...)
- éléments nécessaires/optionnels pour décrire une noisette (nom, description, icônes, blocs, etc.)
- interface de gestion des noisettes (compréhensible, obscure, à simplifier, optimiser...)
- faut-il mieux utiliser xml ou yaml pour décrire les noisettes ? (débat pour le coup plus général puisque les menus et les compositions sont décrits en xml, les saisies en xml mais si j'ai bien compris sont en train de migrer en une description yaml)
- comment défini-t-on les pages sont gérables à un gestionnaire de noisettes ?
- quelles icônes utiliser ? que faut-il uniformiser ? Faut-il utiliser un set d'icônes communes à plusieurs plugins afin d'améliorer l'interface utilisateur ?
- interactions entre les compositions et le gestionnaire de noisettes

oui c'est un problème plus de compréhension et de cohérence que technique, si on mixe des compositions proposées par les squelettes et définies par un fichier, et d'autres ajoutées par le noisetier ...

- interactions entre plugins et Zpip et gestionnaire de noisettes

pour moi :
- les noisettes sont fournies par les plugins (ex les noisettes d'evenement et agenda sont du ressort du plugin agenda, pas d'un autre)
- les squelettes Z n'ont rien à prévoir par défaut.
Par contre l'interaction possible est avec la définition des blocs de la page susceptibles de recevoir des noisettes. Par défaut contenu/, extra/ et navigation/ par exemple.
Mais il faut que celui qui se construit un projet avec plus de blocs puisse les ajouter dans la gestion du noisetier.

- nouvelles saisies à développer
- recourir ou non à des modèles pour afficher les liste d'objets

Tout ce que j'ai pu oublié dans la présente liste...

Oui encore surement plein de choses.
Mais comme je le disais, mon soucis est plutôt de stabiliser et finaliser Z avant de construire un étage de plus, car sinon on va se retrouver avec des trucs figés de fait, bien que de travers, ou vraiment lourd à changer.

C'est la raison pour laquelle je n'ai pas commit (ni marcimat, ni Rastapopoulos) de proposition, et que nous nous sommes contentés pour le moment de jouer dans notre coin pour réfléchir au problème, et bien préparer les fondations.

Cédric

8

Bonjour

Concernant le projet "noisetier" historique, je l'ai pour ma part complètement abandonné : trop ambitieux, pas adapté avec toutes les évolutions qu'a connu SPIP etc.

Dès lors, il mériterait de passer aux archives comme simple état d'une réflexion à un moment donnée (sur la zone, je ne sais pas si la politique serait de le supprimer ou si un répertoire archivage est prévu).

Il faudrait le ranger alors. Soit le déplacer dans _fondation_/ sur la zone si tu penses que le garder sous la main peut être utile, soit le supprimer complètement (sachant qu'il est toujours retrouvable avec svn) sinon.

Pour des raisons de commodités, (et les non expert svn et pour trac)
-> _fondation_/

Km

9

Le 14/02/2010 20:41, cedric.morin@yterium.com a écrit :

Je ne souscris pas à cette approche. Un gestionnaire de noisette doit servir à enrichir des pages. Le fait d'utiliser un tel gestionnaire pour court-circuiter des squelettes ou desactiver des pages me paraît contre-intuitif, et une mauvaise approche.
Tel que je le vois après avoir pris en compte les besoins que tu exprimes :

- le gestionnaire de noisettes permet de gérer tous les types de page, compositions comprises, en ajoutant des noisettes (ou en déplaçant/modifiant celles que le squelette a pu pré-configurer)

Le dernier truc que je comprends pas, c'est en quoi une composition est un type de page. Pour moi une composition est une noisette qui dit : pour cette objet on applique la noisette "article journal" ou "portfolio" ou etc à la partie contenu. Une composition c'est l'ancêtre de la noisette quoi, qui ne peut s'appliquer qu'au contenu et qui ne peut pas se configurer, tandis qu'une noisette c'est pareil sauf que ça a des options configurables et que ça peut se mettre dans plusieurs blocs différents.

- le gestionnaire de noisettes ne court-circuite aucun squelette : il ajoute juste aux squelettes comme contenu/article, extra/article, navigation/article le contenu des noisettes demandées

Oui c'est exactement ce à quoi je pensais : les noisettes se rajoutent avant ou après le contenu existant dans les fichiers écrits en dur. Du coup si ya des choses dans le squelette ça sera toujours présent pour ce type de page. Et si on veut construire un site uniquement à base de noisette, on crée un squelette Z entièrement vide.

Mais du coup, puisqu'il y a ces deux possibilités : tu souscris à cette approche. :slight_smile:

- d'autres projets auront des degrés de libertés moins forts, en choisissant d'avoir toujours un contenu non debrayable
Typiquement, il me parait assez bancal et dangereux de fournir un contenu/article vide sauf à risquer que le webmestre y mette n'importe quoi, y compris du contenu qui n'a rien à voir avec un article. Mais c'est juste mon avis que je ne veux pas imposer.

Oui mais ça, voilà, c'est à chacun de choisir sa méthode : un squelette plein auquel on fait des ajouts, ou un squelette vide qu'on remplit de zéro. Du moment que les deux possibilités fonctionnent... tutti va bene.

pour moi :
- les noisettes sont fournies par les plugins (ex les noisettes d'evenement et agenda sont du ressort du plugin agenda, pas d'un autre)
- les squelettes Z n'ont rien à prévoir par défaut.

Oui, une noisette est en rapport avec une fonctionnalité offerte par un plugin.

Question corollaire à Matthieu : les Saisies ne devraient-elles pas suivre le même principe. Il y a un certain nombre de Saisies qui sont en rapport avec une fonctionnalité d'un plugin : couleur, et les sélecteurs de bonux. Alors pourquoi les regrouper dans Saisies sachant que toutes seules elles ne marchent pas ?

Bon évidemment, au début c'était du "proof of concept", donc c'est normal c'est pour tester. Mais une fois que le "format" sera bien stabilisé, il sera peut-être plus pertinent de les déplacer suivant ce que ça nécessite...

--
RastaPopoulos

10

Le 15/02/2010 04:47, cam.lafit@azerttyu.net a écrit :

Pour des raisons de commodités, (et les non expert svn et pour trac)
-> _fondation_/

Km

Déplacement effectuer dans fondation.

Sur contrib, le tag archive historique a été ajouté à la rubrique concernant le noisetier.

Ne faut-il pas prévoir le déplacement de la rubrique dans une sous-rubrique archive ?

11

Le 15 févr. 2010 à 10:08, RastaPopoulos a écrit :

Le 14/02/2010 20:41, cedric.morin@yterium.com a écrit :

Je ne souscris pas à cette approche. Un gestionnaire de noisette doit servir à enrichir des pages. Le fait d'utiliser un tel gestionnaire pour court-circuiter des squelettes ou desactiver des pages me paraît contre-intuitif, et une mauvaise approche.
Tel que je le vois après avoir pris en compte les besoins que tu exprimes :

- le gestionnaire de noisettes permet de gérer tous les types de page, compositions comprises, en ajoutant des noisettes (ou en déplaçant/modifiant celles que le squelette a pu pré-configurer)

Le dernier truc que je comprends pas, c'est en quoi une composition est un type de page. Pour moi une composition est une noisette qui dit : pour cette objet on applique la noisette "article journal" ou "portfolio" ou etc à la partie contenu. Une composition c'est l'ancêtre de la noisette quoi, qui ne peut s'appliquer qu'au contenu et qui ne peut pas se configurer, tandis qu'une noisette c'est pareil sauf que ça a des options configurables et que ça peut se mettre dans plusieurs blocs différents.

Pour moi une composition est susceptible d'être configurée aussi (même si ce n'est pas encore implémenté) et ça qualifie implicitement le contenu ou au moins une variante. Elle n'a pas vocation a être remplacé par la noisette (car la composition est définie par le redacteur de l'article, sur l'article considére, alors que les noisettes le sont par le webmestre).

Mais les noisettes viennent compléter/prolonger les compositions. En d'autre terme, tu es susceptible de ne pas afficher les mêmes noisettes sur un article-portfolio que sur un article-agenda par exemple

Cédric

12

Le 14/02/2010 19:41, cedric.morin@yterium.com a écrit :

Je ne souscris pas à cette approche. Un gestionnaire de noisette doit servir à enrichir des pages. Le fait d'utiliser un tel gestionnaire pour court-circuiter des squelettes ou desactiver des pages me paraît contre-intuitif, et une mauvaise approche.
Tel que je le vois après avoir pris en compte les besoins que tu exprimes :

- le gestionnaire de noisettes permet de gérer tous les types de page, compositions comprises, en ajoutant des noisettes (ou en déplaçant/modifiant celles que le squelette a pu pré-configurer)
- le gestionnaire de noisettes ne court-circuite aucun squelette : il ajoute juste aux squelettes comme contenu/article, extra/article, navigation/article le contenu des noisettes demandées
- ainsi, un concepteur de squelette peut choisir de mettre certains contenus en "dur" dans les squelette ou compositions, et d'autre sous forme de noisettes avec une pré-configuration par défaut (une liste des noisettes pour chaque page et chaque bloc)

- ceux qui veulent, comme toi, pouvoir tout gérer par le gestionnaire de noisettes peuvent prévoir une squelette Z où tout est en noisettes et modifiable, donc. Avec une configuration comme tu le propose ci-dessous.

- d'autres projets auront des degrés de libertés moins forts, en choisissant d'avoir toujours un contenu non debrayable
Typiquement, il me parait assez bancal et dangereux de fournir un contenu/article vide sauf à risquer que le webmestre y mette n'importe quoi, y compris du contenu qui n'a rien à voir avec un article. Mais c'est juste mon avis que je ne veux pas imposer.

La notion de page activable/désactivable telle qu'elle est implémentée en l'état dans le prototype noiZetier ne signifie pas qu'une page désactivée ne renvoie rien. Une page désactivée renvoie les squelettes prévus pour cette page (et donc cela passe effectivement techniquement par le fait que le noiZetier ne court-circuite pas l'appel au squelette).
Pour le moment, le noiZetier n'est pas un squelette autonome dans la mesure où il vient s'ajouter à Zpip et effectievement cour-circuite Zpip pour l'affichage des contenus. Peut-être une autre approche serait plus pertinente.

Je retiens qu'il faut distinguer deux cas de figure / deux type d'utilisateurs :
- Des contenus non débrayables, l'utilisateur pouvant simplement compléter les contenus de certaines pages.
- Le cas où l'on souhaite pouvoir gérer tous les contenus via un noisetier, ce qui peut aussi concerner, outre quelqu'un comme moi, celui qui n'y connais rien au code et à l'écriture de squelette et veut avoir un large choix d'option de personnalisation.

Il y a probablement plusieurs manières d'y arriver.
- Dans l'approche actuelle (surcharge de Zpip, ce qui ne veut pas dire qu'elle est la bonne), il faut trouver une convention pour indiquer des fichiers à inclure tant tous les cas, que le noisettes déclarées viennent compléter.
- Dans ce que je devine de ta pensée (mais n'hésite pas à me dire si je me trompe), c'est un squelette Z qui va informer le générateur de noisettes des pages gérables et des blocs configurables (qui pourraient même être différents pour chaque page) et qui dans ses squelettes fera appel au gestionnaire de noisettes via un inclure par exemple.
Autrement dit, on pourrait trouver par la suite le squelette Zpip tel qu'actuellement qui fonctionne sans gestionnaire de noisette, un squelette Z qui fournit un minimum de contenus non débrayables avec la possibilité de les compléter par les noisettes des plugins, et un squelette Z dont tous les contenus sont noisetables et qui fournirait par ailleurs les noisettes nécessaires aux contenus de base.
Ces deux derniers squelettes Z ayant recours à un même gestionnaire de noisettes commun. Ce dernier ne court-circuite aucun squelette mais doit être appelé explicitement.

Il semble juste que le noisetier devra proposer un pipeline pour lister les pages disponibles, ce qui permettra aux autres plugins d'ajouter ou supprimer des pages configurables (ça n'a pas de sens de laisser configurable une page qui a été bloquée par ailleurs).

- interactions entre les compositions et le gestionnaire de noisettes

oui c'est un problème plus de compréhension et de cohérence que technique, si on mixe des compositions proposées par les squelettes et définies par un fichier, et d'autres ajoutées par le noisetier ...

Ce que je voulais tester dans le noiZetier était l'approche suivante : la possibilité de créer des compositions directement depuis l'espace privé. Un formulaire me liste les pages pouvant admettre une composition (article, rubrique, etc.), je fournis un identifiant, un nom, une description et optionnellement une icone.

Pour le noiZetier, tel qu'il est actuellement, il s'agit simplement d'une page comme une autre, dont on peut modifier les noisettes. La règle actuelle qui consiste à dire que si un bloc ne contient pas de noisettes, alors on affiche les noisettes de la page parente, fait qu'une composition article-compo affichera une page article tant qu'on n'aura pas modifié sa configuration de noisettes.
Il n'y a pas de squelettes effectivement présent pour cette composition. C'est via styliser que l'on renvoie sur le gestionnaire de noisettes.
Reste toujours la possibilité de créer une composition physiquement (via un squelette) en écrivant un fichier xml dans contenu. Dès lors, la composition dans la version actuelle il faut la déclarer comme page gérable par le noisetier.

Cela implique néanmoins dans Composition un pipeline pour lui indiquer la composition dans la liste des compos disponibles.

Dans le cas de contenus non débrayables, les compositions créées via le gestionnaire de noisette sont des variations sur une page dont seule la partie noisettes est différentes (on appelle le bloc d'une page en lui passant un paramètre composition).

Éventuellement, cette option peut être désactivable (si un webmestre) ne veut pas la rendre possible à ses utilisateurs et qu'il veut contrôler les compositions disponibles.

- interactions entre plugins et Zpip et gestionnaire de noisettes

pour moi :
- les noisettes sont fournies par les plugins (ex les noisettes d'evenement et agenda sont du ressort du plugin agenda, pas d'un autre)

Je suis tout à fait d'accord que les noisettes doivent être fournies par les plugins dont elles dépendent. De même que les noisettes doivent être utilisables en l'absence d'un gestionnaire de noisettes.

La question que je me pose par contre, c'est qui doit fournir une page évènement ? Et dans ce cas là de quelle manière ?

Ce que je souhaitais tester dans l'optique du noiZetier dans son état actuel (je sais que la page évènement n'est pas encore formalisé), c'était une page évènement qui testait la présence d'un squelette Z. S'il avait un squelette Z, alors cela appelait structure.html sinon cela fournissait un contenu par défaut. Par ailleurs, étaient fournis contenu/evenement navigation/evenement et extra/evenement.
Enfin, la page était déclarée activable par le noiZetier.

La page evenement fourni par Agenda était donc utilisable sans autre plugin activé sur le site (compatible avec dist), utilisable avec seulement Zpip activé, et utilisable avec Zpip + noizetier.
Elle pouvait donc être fournie par le plugin Agenda et restait surchargeable par un squelette non Z.

- les squelettes Z n'ont rien à prévoir par défaut.

Dans l'optique où le noiZetier venait surcharger Zpip, le squelette Zpip devait fournir son fonctionnement en l'absence de noiZetier (ce qu'il fait actuellement).

Dans l'optique de différents squelettes Z qui appellent explicitement un gestionnaire de noisettes, la question se pose de fait différemment.

Par contre l'interaction possible est avec la définition des blocs de la page susceptibles de recevoir des noisettes. Par défaut contenu/, extra/ et navigation/ par exemple.
Mais il faut que celui qui se construit un projet avec plus de blocs puisse les ajouter dans la gestion du noisetier.

Sur une réorganisation où un squelette Z appelle explicitement un gestionnaire de noisettes, il suffit que la déclaration des pages sur lesquelles le gestionnaire de noisettes s'applique intègre, pour chaque page, les blocs existants. A l'interface du gestionnaire de noisettes de gérer ces différents blocs.

Mais comme je le disais, mon soucis est plutôt de stabiliser et finaliser Z avant de construire un étage de plus, car sinon on va se retrouver avec des trucs figés de fait, bien que de travers, ou vraiment lourd à changer.

C'est la raison pour laquelle je n'ai pas commit (ni marcimat, ni Rastapopoulos) de proposition, et que nous nous sommes contentés pour le moment de jouer dans notre coin pour réfléchir au problème, et bien préparer les fondations.

Ce qui n'interdit pas de tester différentes approches.

Bien cordialement

Joseph

13

Le 15 févr. 2010 à 11:49, Joseph a écrit :

Dans l'optique où le noiZetier venait surcharger Zpip, le squelette Zpip devait fournir son fonctionnement en l'absence de noiZetier (ce qu'il fait actuellement).

Dans l'optique de différents squelettes Z qui appellent explicitement un gestionnaire de noisettes, la question se pose de fait différemment.

Je ne comprends pas cette dichotomie.
Le gestionnaire de noisette ne doit pas surcharger mais enrichir.
Et les squelettes Z n'ont pas a appeler quoi que ce soit.

C'est tout à fait transparent de ce point de vue, tout du moins tant que le squelette fourni son contenu de façon classique. Lorsque un gestionnaire de noisette existera et sera bien défini, des variantes de Z reposant sur un assemblage de noisettes nécessiteront dans ce cas le gestionnaire, seul à même de lire la configuration et l'assemblage par défaut.

La question que je me pose par contre, c'est qui doit fournir une page évènement ? Et dans ce cas là de quelle manière ?

Le plugin agenda, sans aucun doute, et sous forme de contenu/evenement (qui mappe l'objet evenement) et contenu/page-agenda, avec après d'éventuelles briques de navigation (mini calendrier).

Ce que je souhaitais tester dans l'optique du noiZetier dans son état actuel (je sais que la page évènement n'est pas encore formalisé), c'était une page évènement qui testait la présence d'un squelette Z. S'il avait un squelette Z, alors cela appelait structure.html sinon cela fournissait un contenu par défaut.

Non il faut abandonner cette approche. La dist est un squelette exemple qui est forké à tout bout de champ. Un squelette par défaut basé sur la dist n'est jamais utilisable tel quel, cela fait 9 ans qu'on est face à ce blocage.

Un plugin comme agenda doit proposer les composants pour les squelettes de type Z car c'est la structure générique et partagée qu'il faut développer et la seule qui permet un fonctionnement immédiat des pages concernées, dans manipulation.
Pour ceux qui utilisent des squelettes ne reposant par sur l'architecture de Z, il faudra qu'ils ajoutent les inclusions à la main. Ce sera toujours mieux que d'avoir une page complète par défaut basée sur la dist et qui sera toute bancale ou inutilisable, mais aura le mauvais gout d'être présente à tort.

Par ailleurs, étaient fournis contenu/evenement navigation/evenement et extra/evenement.
Enfin, la page était déclarée activable par le noiZetier.

je ne comprends pas toujours cette notion d'activable ou pas. C'est un non sens.
Si pas de gestionnaire de noisette ça doit marcher tout seul.
Et si un gestionnaire de noisettes est là il doit permettre de gérer toutes les pages du site tout seul comme un grand, sans reposer sur un mécanisme de déclaration ou je ne sais quoi.
Après on peut prévoir un mécanisme d'autorisation pour permettre à un webmestre de bloquer la modification de certains type de page, mais c'est une autre question.

La page evenement fourni par Agenda était donc utilisable sans autre plugin activé sur le site (compatible avec dist),

Aucun intérêt, comme je le disais. Cela est possible depuis 3 ans, mais personne ne l'a fait. C'est que ça n'intéresse personne en pratique car ce n'est pas utilisable.

utilisable avec seulement Zpip activé, et utilisable avec Zpip + noizetier.
Elle pouvait donc être fournie par le plugin Agenda et restait surchargeable par un squelette non Z.

Je pense que tu échafaude des mécanismes compliqués alors que justement, ce qu'on essaye de faire avec Z c'est une architecture très simple, où les briques se branchent ensemble très simplement, avec des règles claires.

Les mécanismes à partir de surcharge-oui-mais-non-pas-là-dans-ce-dossier-ce-coup-ci-parce-qu'il-y-a-tel-plugin- mais-sinon-c'est-un-autre-qui-le-déclare-et-faut-voir-quel-fichier-on-personalise-a-la-fin c'est exactement le genre d'approche que je veux éviter à tout prix.

Et c'est la raison pour laquelle il faut prendre le temps de concevoir l'ensemble du projet, de réfléchir à l'éco-système, et de faire des choix (typiquement renoncer à la compatibilité avec la dist est un choix que je revendique haut et fort car il n'apporte que des lourdeurs et aucun bénéfice pour les utilisateurs).

Cédric

14

Le 15/02/2010 10:26, cedric.morin@yterium.com a écrit :

Pour moi une composition est susceptible d'être configurée aussi (même si ce n'est pas encore implémenté) et ça qualifie implicitement le contenu ou au moins une variante. Elle n'a pas vocation a être remplacé par la noisette (car la composition est définie par le redacteur de l'article, sur l'article considére, alors que les noisettes le sont par le webmestre).

Mais les noisettes viennent compléter/prolonger les compositions. En d'autre terme, tu es susceptible de ne pas afficher les mêmes noisettes sur un article-portfolio que sur un article-agenda par exemple

Mais justement, ça fait des inclusions d'inclusions d'inclusions... Je vois pas l'utilité.

On a alors le squelette Z, qui peut inclure des compositions configurables qui elles-mêmes peuvent inclurent des noisettes configurables !...

D'après ce que tu me décris, la composition est, *de fait*, une noisette : c'est un morceau de squelette qui est configurable (dont les options sont décrites) et que l'on intègre quelque part. Techniquement c'est exactement la même chose. Donc dans ce que tu dis, il n'y a que le type d'utilisateur qui diffère entre les deux, les autorisations en somme. C'est alors plus une problème d'ergonomie, d'interface, et de gestion des autorisations, plutôt que deux plugins séparés qui proposent en fait la même chose techniquement.

Une composition est une noisette appliqué à un objet précis par le créateur de celui-ci, et uniquement pour la partie contenu. Voilà pourquoi je disais "l'ancêtre" des noisettes qui consiste en la même chose mais en plus générique.

Prenons le type d'objet "article". Quand on utilise le noisetier, on pourrait alors choisir :
- les noisettes dans les différents blocs pour *tous* les articles (pour webmestre)
- surchargeable par les noisettes pour les articles *d'une rubrique* ( pour webmestre et admins y compris restreint ?)
- surchargeable par les noisettes de l'article 23, y compris pour le bloc contenu donc ! à la place de la compo (pour auteurs de l'article)

Chaque niveau surcharge donc remplace le précédent à partir du moment où on le configure.

Lorsqu'on l'on veut des trucs qui reste sur TOUS les articles, quelques soient les noisettes configurées, alors :
- soit on met des choses en dur dans les squelettes
- soit on utilise la config "tous" des noisettes, qui permet de dire qu'une noisette est présent à tel endroit toujours, même quand on configure un niveau plus précis.

--
RastaPopoulos

15

Hello,

Le 15 février 2010 13:21, cedric.morin@yterium.com <cedric.morin@yterium.com> a écrit :

Et c’est la raison pour laquelle il faut prendre le temps de concevoir l’ensemble du projet, de réfléchir à l’éco-système, et de faire des choix (typiquement renoncer à la compatibilité avec la dist est un choix que je revendique haut et fort car il n’apporte que des lourdeurs et aucun bénéfice pour les utilisateurs).

Je plussoie totalement aux remarques de Cedric sur le sujet.
Il est vraiment important de converser voire d’améliorer la simplicité de mise en oeuvre des squelettes Z et de ses « add-ons » et donc de partager les réflexions avant de se lancer dans le code.

Repartir à chaque fois de zéro est lassant et contre productif même si cela parait de prime abord plus facile… Si l’on se concentre sur le Noisetier, quelles sont aujourd’hui les différentes réflexions et expériences sur le sujet et qu’en sort-il ? J’avoue que j’aimerais bien le savoir avant de me lancer dans un nouveau NoiZetier…

Enfin, il me semble qu’avant de rajouter une pierre à l’édifice Z il serait bon de finir de bétonner la première en figeant par exemple la nomenclature sur laquelle d’ailleurs le noiZetir devra s’appuyer pour proposer la sienne…

++
Eric

16

Le 15 févr. 2010 à 13:25, RastaPopoulos a écrit :

Le 15/02/2010 10:26, cedric.morin@yterium.com a écrit :

Pour moi une composition est susceptible d'être configurée aussi (même si ce n'est pas encore implémenté) et ça qualifie implicitement le contenu ou au moins une variante. Elle n'a pas vocation a être remplacé par la noisette (car la composition est définie par le redacteur de l'article, sur l'article considére, alors que les noisettes le sont par le webmestre).

Mais les noisettes viennent compléter/prolonger les compositions. En d'autre terme, tu es susceptible de ne pas afficher les mêmes noisettes sur un article-portfolio que sur un article-agenda par exemple

Mais justement, ça fait des inclusions d'inclusions d'inclusions... Je vois pas l'utilité.

On a alors le squelette Z, qui peut inclure des compositions configurables qui elles-mêmes peuvent inclurent des noisettes configurables !...

D'après ce que tu me décris, la composition est, *de fait*, une noisette : c'est un morceau de squelette qui est configurable (dont les options sont décrites) et que l'on intègre quelque part. Techniquement c'est exactement la même chose. Donc dans ce que tu dis, il n'y a que le type d'utilisateur qui diffère entre les deux, les autorisations en somme.

La composition est le point de repère qui nomme et définit comment sera mis en forme un contenu, même si techniquement cela ressemble et c'est juste un squelette inclus.

C'est alors plus une problème d'ergonomie, d'interface, et de gestion des autorisations, plutôt que deux plugins séparés qui proposent en fait la même chose techniquement.

Une composition est une noisette appliqué à un objet précis par le créateur de celui-ci, et uniquement pour la partie contenu. Voilà pourquoi je disais "l'ancêtre" des noisettes qui consiste en la même chose mais en plus générique.

Prenons le type d'objet "article". Quand on utilise le noisetier, on pourrait alors choisir :
- les noisettes dans les différents blocs pour *tous* les articles (pour webmestre)
- surchargeable par les noisettes pour les articles *d'une rubrique* ( pour webmestre et admins y compris restreint ?)
- surchargeable par les noisettes de l'article 23, y compris pour le bloc contenu donc ! à la place de la compo (pour auteurs de l'article)

Moi tu proposes d'attacher les noisettes à un objet/id_rubrique/id_objet, ce qui est le prolongement de la methode des squelettes-xx qui a plein de lourdeurs

Moi je propose que les compositions correspondent à des assemblages pré-configurés, et sur tel article tu applique la composition portfolio, sur tel autre la composition forum etc ...
Le rédacteur ne va pas s'amuser à configurer article par article ses noisettes, et le webmestre ne va pas repasser derrière chaque article publié pour dire 'ah là il fallait telles noisettes'.

Le webmestre définit des compositions, qui sont un ensemble de [un contenu principal formaté + une liste de noisettes configurées], et au quotidien, les rédacteurs choisissent juste le type de composition à appliquer à leur contenu, comme actuellement dans compositions.

Chaque niveau surcharge donc remplace le précédent à partir du moment où on le configure.

Lorsqu'on l'on veut des trucs qui reste sur TOUS les articles, quelques soient les noisettes configurées, alors :
- soit on met des choses en dur dans les squelettes
- soit on utilise la config "tous" des noisettes, qui permet de dire qu'une noisette est présent à tel endroit toujours, même quand on configure un niveau plus précis.

Compliqué ça. Pour moi il y a la configuration 'article' par défaut, puis les variantes pour chaque composition.
Lors de la définition des variantes, on propose de repartir d'une composition existante, ce qui simplifie le travail du webmestre qui a juste à faire les changements.
Les mécanismes d'héritage, de surcharge de propagation etc ... c'est compliqué à appréhender pour les utilisateurs.

Cédric

17

Le 15/02/2010 14:07, cedric.morin@yterium.com a écrit :

Moi tu proposes d'attacher les noisettes à un objet/id_rubrique/id_objet, ce qui est le prolongement de la methode des squelettes-xx qui a plein de lourdeurs

C'est pourtant ce que font les compositions ! Même si ya pas (encore :)) la notion d'appliquer à toute une branche.

La seule différence est le contenu du champ :
- composition => juste le nom de la compo
- noisettes => un tableau sérialisé décrivant la liste des noisettes et leurs options

Moi je propose que les compositions correspondent à des assemblages pré-configurés, et sur tel article tu applique la composition portfolio, sur tel autre la composition forum etc ...
Le rédacteur ne va pas s'amuser à configurer article par article ses noisettes, et le webmestre ne va pas repasser derrière chaque article publié pour dire 'ah là il fallait telles noisettes'.

Le webmestre définit des compositions, qui sont un ensemble de [un contenu principal formaté + une liste de noisettes configurées], et au quotidien, les rédacteurs choisissent juste le type de composition à appliquer à leur contenu, comme actuellement dans compositions.

Ok j'ai enfin compris, et c'est complètement différent au final.

À partir du moment où les compositions utilisent des noisettes (puisque ce n'est pas une obligation non plus), alors les compositions sont des *ensembles pré-configurés* de noisettes dans *différents blocs*.

Et pour le coup, le nom du plugin prend enfin tout son sens : on prend des noisettes et on les compose pour en faire des ensembles, que les rédacteurs et admins pourront ensuite appliquer.

Maintenant que j'ai compris, je suis d'accord, c'est plutôt cool. :slight_smile:

Enfin... je suis d'accord pour dire que c'est pratique dans la majorité des cas. Maintenant si je veux que mon article 23 est un bloc supplémentaire en colonne de nav, ou bien si je veux que tous les articles de ma rubrique "blog" aient un mini-calendrier dans une colonne ?

Je suis donc d'accord pour dire que les compositions ne sont pas en fait pas du tout des noisettes, mais je continue de penser que le noisetier doit permettre plus que juste appliquer des compositions de noisettes pré-fabriquées en amont.

--
RastaPopoulos

18

Le 15/02/2010 14:16, RastaPopoulos a écrit :

Enfin... je suis d'accord pour dire que c'est pratique dans la majorité
des cas. Maintenant si je veux que mon article 23 est un bloc
supplémentaire en colonne de nav, ou bien si je veux que tous les
articles de ma rubrique "blog" aient un mini-calendrier dans une colonne ?

Est-ce que cela n'est pas du ressort du plugin Compositions ?
Qu'il soit possible d'appliquer une composition par défaut à tous les objets d'une rubrique donnée ?
Par exemple, d'appliquer une composition article-agenda à tous les articles de la rubrique Agenda plutôt que d'avoir à activer cette composition manuellement pour chaque article de la rubrique ?

Joseph

19

Le 15/02/2010 12:21, cedric.morin@yterium.com a écrit :

C'est tout à fait transparent de ce point de vue, tout du moins tant que le squelette fourni son contenu de façon classique. Lorsque un gestionnaire de noisette existera et sera bien défini, des variantes de Z reposant sur un assemblage de noisettes nécessiteront dans ce cas le gestionnaire, seul à même de lire la configuration et l'assemblage par défaut.

Et c'est cette variante qui spécifiera où doivent être incluses définies par l'éditeur de noisettes ?

Un plugin comme agenda doit proposer les composants pour les squelettes de type Z car c'est la structure générique et partagée qu'il faut développer et la seule qui permet un fonctionnement immédiat des pages concernées, dans manipulation.
Pour ceux qui utilisent des squelettes ne reposant par sur l'architecture de Z, il faudra qu'ils ajoutent les inclusions à la main. Ce sera toujours mieux que d'avoir une page complète par défaut basée sur la dist et qui sera toute bancale ou inutilisable, mais aura le mauvais gout d'être présente à tort.

Faudra-il un squelette racine evenement.html qui fait appel à structure.html comme actuellement ou bien Z sera-t-il en capacité de créer la page juste à partir de contenu/evenement navigation/evenement ... ?

Si pas de gestionnaire de noisette ça doit marcher tout seul.
Et si un gestionnaire de noisettes est là il doit permettre de gérer toutes les pages du site tout seul comme un grand, sans reposer sur un mécanisme de déclaration ou je ne sais quoi.
Après on peut prévoir un mécanisme d'autorisation pour permettre à un webmestre de bloquer la modification de certains type de page, mais c'est une autre question.

Comment détermine-t-il quelles sont les pages qu'il doit gérer ? Il s'agirait de tout squelette situé à la racine ? Une autre manière ?

20

Le 15/02/2010 13:04, Eric a écrit :

Hello,

Le 15 février 2010 13:21, cedric.morin@yterium.com
<mailto:cedric.morin@yterium.com> <cedric.morin@yterium.com
<mailto:cedric.morin@yterium.com>> a écrit :

    Et c'est la raison pour laquelle il faut prendre le temps de
    concevoir l'ensemble du projet, de réfléchir à l'éco-système, et de
    faire des choix (typiquement renoncer à la compatibilité avec la
    dist est un choix que je revendique haut et fort car il n'apporte
    que des lourdeurs et aucun bénéfice pour les utilisateurs).

Je plussoie totalement aux remarques de Cedric sur le sujet.
Il est vraiment important de converser voire d'améliorer la simplicité
de mise en oeuvre des squelettes Z et de ses "add-ons" et donc de
partager les réflexions avant de se lancer dans le code.

Repartir à chaque fois de zéro est lassant et contre productif même si
cela parait de prime abord plus facile... Si l'on se concentre sur le
Noisetier, quelles sont aujourd'hui les différentes réflexions et
expériences sur le sujet et qu'en sort-il ? J'avoue que j'aimerais bien
le savoir avant de me lancer dans un nouveau NoiZetier...

Enfin, il me semble qu'avant de rajouter une pierre à l'édifice Z il
serait bon de finir de bétonner la première en figeant par exemple la
nomenclature sur laquelle d'ailleurs le noiZetir devra s'appuyer pour
proposer la sienne...

++
Eric

Je prends note qu'il est trop tôt pour discuter d'un gestionnaire de noisettes et qu'il faut attendre que d'autres éléments des squelettes Z soient finalisés / stabilisés.

Je m'excuse pour le dérangement et reviendrai participer à cette discussion ultérieurement.

Du coup, il me semble pertinent d'effacer le répertoire noizetier de la zone. Ca évitera que certains tombent dessus sans savoir ce que c'est.

Bien cordialement

Joseph