Bonjour à tous,
c'est avec un grand plaisir que je viens de voir sortir ACS et le début de discussion sur la liste sur la gestion des noisettes vient une interface dans l'espace privée.
Vous l'aurez constaté, le projet du noisetier est au point mort. je viens de passer une année intense d'un point de vue professionnel et je n'ai eu absolument pas le temps de m'y consacrer (surtt que je suis lent à faire vu que je ne suis pas développeur).
A défaut d'avoir codé, je me permets ici quelques remarques sur ce qui me semble important des fonctionnalités que devrait incorporé un plugin de gestion de noisettes (ou de composants).
Il me semble que pour éviter de multiples projets en parallèle, il serait pertinent d'aboutir à poser un modèle de ce que doit être une noisette. Il me semble que ce modèle doit permettre de gérer les points suivants :
-* gestion des différentes traductions et de la description de l'espace privé ;
-* précision des différents paramètres concernant le contenu affiché par la noisette et également ceux des css propres à la noisette ;
-* préciser les variables d'environnement (obligatoires et optionnelles) nécessaires au fonctionnement d'une noisette le cas échéant (une noisette liste des 10 derniers articles n'en a pas besoin, mais une noisette forum d'un article nécessite un id_article) ;
-* précise les mots clés techniques nécessaires au fonctionnement de la noisette (une noisette articles mis en avant car taggés par le mot clé en-avant nécessite que ce mot clé existe). Outre le nom du mot clé, il faut précisé sur quel type d'objet il porte ;
-* il doit y avoir un nommage de boîte, classe CSS le plus uniforme possible entre les noisettes afin que différents squelettes puissent les utiliser ;
-* une compatibilité crayon ;
-* un numéro de version de chaque noisette pour pouvoir gérer une mise à jour de ces dernières (je mets à jour le plugin, certaines noisettes proposent désormais de nouveaux paramètres, le plugin peut alors véirifier les noisettes mises à jours et rajouter les nouveaux paramètres éventuels) ;
-* préciser les plugins (ou la version du plugin) nécessaires au fonctionnement de la noisette le cas échéant et la version de spip requise au besoin(par exemple une noisette liste des dernières newsletters envoyées ne devraient pouvoir être installées que si spip-liste est activé, pareil pour une noisette prochain évènement ayant besoin de spip_agenda) ;
-* les insertions dans l'entête html nécessaires si la noisette est présente dans la page le cas échéant (par exemple une noisette nécessitant un javascript donné...) ;
-* et éventuellement, le cas échéant, les squelettes compatibles ou incompatibles avec cette noisette.
Le modèle de noisettes présents dans ACS me semble, à première vue (son auteur peut me corriger si je me trompe) comprendre un ensemble important de ces points mais pas tous pour le moment. Il me semble qu'il suffirait juste d'ajouter quelques champs au xml de description de la noisette (appelée composant dans ACS si je ne m'abuse. Je continuerai à user du terme noisette ici néanmoins).
Dans ACS, les noisettes sont dans un sous-répertoire composants du modèle de squelette. Il semble alors qu'une noisette est destinée à un seul squelette. Il me semblerait plus pertinent que tous les noisettes soient dans un même répertoire, utilisables ainsi par tous les squelettes (avec la précision des squelettes incompatibles dans le xml le cas échéant). Par ailleurs, il faudrait pouvoir déclarer ses propres noisettes dans squelettes et pouvoir aussi en distribuer dans d'autres plugins à terme (en effet, si un modèle de noisette se généralise, on pourrait par exemple envisager que le plugin agenda soit livré avec des noisettes compatibles prêtes à l'emploi). dans le noisetier, on considérait comme noisettes toutes celles qui sont dans un sous-répertoire noisettes, qu'il soit dans n'importe quel plugin ou bien dans le répertoire squelettes. On peut choisir un autre nom de répertoire, mais une uniformisation sur ce point me semble important. Dans ACS, je ne sais pas dans quelle mesure on peut déclarer des noisettes ailleurs mais je suppose que son auteur pourra préciser ce point.
Dans ACS, certains composants fournissent du contenu (edito, bannière, rubnav...) alors que d'autres sont en réalité des contenus de composants (colonne1, colonne2, entete...). Par ailleurs, ces conteneurs ont un nombre de contenu limité.
Il me semble que ces éléments doivent être clairement séparés pour l'utilisateur final. Dans le noisetier, nous parlions de noisettes et de zones. Les zones étant définis par le squelette utilisé. Un squelette peut ainsi utilisé une colonne de gauche, un entete, un corps et un pieds de page, tandis qu'un autre squelette peut proposer une mise en page en trois colonnes. Dans certains squelettes, toutes les pages n'ont pas les mêmes zones. Par exemple, dans la dist, la page login ne dispose pas d'en-tete ni de pied de page. Il me semble que c'est au squelette de définir les zones disponibles (structure type et pages spécifiques) et au gestionnaire de noisettes de remplir ensuite ces conteneurs avec les différentes noisettes requises, dans le bon ordre et avec les paramètres adéquats. Le système à adopter doit permettre de pouvoir mettre autant de noisettes que voulu dans une zone (sans être limité en nombre) via un système générique.
Si un squelette permet de modifier le nombre de zones (par exemple multiflex où on peut changer la mise en page) à lui alors de permettre cette gestion plus fine.
Les CSS des différents composants d'ACS peuvent être personnalisées de manière très fines ce qui me semblent très intéressants. Il me semblerait un plus qu'il y ait dans les noisettes également une personnalisation des contenus (par exemple, choisir dans une noisette liste des derniers articles le nombre d'articles à afficher).
Par ailleurs, cela rejoint le point sur la problématique de trouver un nommage CSS relativement standard, il faudrait arriver à ce que les noisettes aient un habillage par défaut dépendant de la css générique du squelette (cette CSS pouvant par exemple définir que les éléments de type h3 dans la colonne de droite sont en gras et en vert). La personnalisation des CSS pour chaque composant ne serait alors qu'une surcharge de cette CSS standard pour un composant particulier. On aurait ainsi à la fois un habillage par défaut et une possibilité de personnalisation. (Il est probable qu'ACS propose déjà cela mais il me semble que l'habillage par défaut soit très limité). De fait, un petit lien 'Effacer l'habillage CSS personnalisé' dans la page de gestion d'un composant me semblerait un petit plus.
À partir d'un ensemble de noisettes, on peut envisager différents modèles de sites ou distributions. Une distribution type journal ou bien type blog, ou bien minimale. À terme, il me semble qu'il serait pertinent qu'un système de gestion des noisettes puissent gérer des fichiers de distribution (probalement un xml) spécifiant une configuration particulière des noisettes. Cela faciliterait l'installation. De plus, on pourrait alors sauvegarder sa propre distribution.
J'ai l'impression que pour le moment ACS n'installe pas les mots clés techniques nécessaires à certaines noisettes. À terme, un gestionnaire de noisettes devrait pouvoir installer (et éventuellement désinstaller) les mots clés techniques nécessaires aux noisettes utilisées sur le site. Par ailleurs, comme SPIP ne gèrent pas pour le moment les mots-clés techniques, il est nécessaire d'utiliser une seule et même manière de les filtrer sur le site public (certains squelettes utilisent par exemple les caractères ~ ou _ pour préfixer le nom des groupes de mots clés techniques).
Concernant la gestion des droits avancés d'accès et des droits d'administrations, il me semble que cela n'a pas sa place dans un tel plugin mais devrait faire l'objet de plugins séparés. La fait d'avoir une gestion fine des droits d'accès dans l'espace privé devrait être intégré au plugin autorité. Concernant les droits de gérer le plugin, il existe le statut webmaster dorénavant avec autorité (statut encore plus large que admin général). Par ailleurs, la restriction de certaines pages de l'espace privé à certains utilisateurs n'est pas spécifique à ACS. Ces différentes fonctionnalités auraient toutes leur place dans Autorité, on pourrait ainsi les utiliser sans utiliser ACS. Par ailleurs, si on considère qu'il est vraiment fondamental pour ACS d'utiliser parallèlement une gestion avancée de droits, alors, on peut rajouter un nécessite autorité.
Concernant la restriction d'accès, il me semble que le filtrage réalisé par ACS est un filtrage objet par objet par mots-clés. Cela pour moi devrait faire l'objet d'un plugin séparé utilisant une surcharge des boucles SPIP. Dans ACS, cela se fait via des éléments dans le squelettes, ce qui fait déjà qu'on a une page article et inc_article (ca complique le système pour l'utilisateur néofite) mais de plus c'est une contrainte forte sur la rédaction de squelette. Le filtrage directement dans les boucles SPIP me semble plus pertinent. Une restriction objet par objet est un fonctionnement différent qu'une restriction par branche. Et donc cela peut faire l'objet d'un plugin distinct de accès_restreint (même si probablement une partie du code sera commune).
Le système doit également être suffisamment générique pour que n'importe quel contenu puisse être diffusé via une noisette (et même tous les contenus de la page). Ainsi, même l'ensemble Titre/Texte/note d'un article doit pouvoir faire l'objet d'une noisette, ainsi que la liste des documents joints, le forum, la pétition et les mots clés attachés. je peux ainsi choisir où je place ces différents éléments dans la page. par exemple, les mots clés attachés après l'arbre des rubriques mais avant le texte, les docs joints dans la colonne de gauche et la pétition avant le forum etc. Or, pour pouvoir afficher n'importe quelle noisette, il faut pouvoir lui passer les variables d'environnement dont elle a besoin. C'est souvent un des noeuds du problème lorsque l'on fait une inclusion. C'est pourquoi il importe que les variables d'environnement d'une noisette soient précisées dans son xml. Une solution consiste à passer à chaque noisette l'ensemble des variables d'environnement. Mais cela multiplie le cache. Dans BliP, seul était passé l'id en cours. mais dans ce cas là, impossible d'utiliser une pagination. Dans le noisetier, seuls les variables d'environnement propres à une noisette lui sont passées mais la bidouille utilisée n'est probablement pas la meilleure manière de faire.
J'évoquais précédemment la notion de variable d'environnement obligatoire et optionnelle. Prenons un exemple, une noisette affichant la liste des signataires d'une pétition avec une pagination de 100 signataires. Il faut impérativement à cette noisette un id_article afin de renvoyer un résultat. Il s'agit alors d'une variable d'environnement obligatoire et le système ne devrait autorisé l'installation de cette noisette uniquement sur une page fournissant un id_article. Mais cette noisette nécessite également une autre variable d'environnement (celle de la pagination) ou bien une variable de tri qui serait passée en URL. ces deux variables doivent être transmises à la noisette si elles sont présentes mais ne sont pas obligatoires, donc optionnelles.
Je ne sais pas pour le moment comment cela est gérer dans ACS. Il me semble que chaque noisette dispose d'un squelette d'appel qui lui passe uniquement les variables d'environnement qui lui sont nécessaires ainsi que les éléments de configuration en var d'environnement. Mais cela est à confirmer par son auteur. Néanmoins, le choix retenu pour le squelette de démonstration cat est de ne pas gérer tout le contenu par des noisettes puisqu'une partie est inclue directement dans les squelettes.
L'exemple précédent renvoie à la notion de page. Il me semble que cette dernière mérite d'être creusée et que l'on peut distinguer page et squelette. Il peut y avoir de nombreux squelettes et inclusions d'un point de vue technique, pour un utilisateur lambda il n'est pas forcément nécessaire de connaître toutes ces inclusions. Je vais afficher un élément sur une page article ou une page sommaire ou bien sur toutes les pages. Autrement dit, il faut pouvoir spécifier à une noisette si on l'affiche sur toutes les pages, sur certaines pages uniquement, ou sur toutes les pages sauf certaines. les pages doivent avoir leur propre définition qui précise notamment les variables d'environnement qu'elles délivrent systématiquement, la page article ayant toujours un id_article. Dès lors, une noisette ayant un id_article obligatoire ne pourra être installée que sur ces pages, alors qu'une noisette sans var obligatoire pourra être installée sur toutes les pages.
La définition des pages ne doit pas dépendre me semble-t-il des squelettes, ces derniers ne devant définir que les zones. Et une page devrait pouvoir être définies par d'autres plugins. Par exemple, supposons que j'installe le plugin spip-listes, alors ce plugin devrait pouvoir à la fois livrer des noisettes spécifiques reconnues par le système mais également pouvoir définir une page courier et liste_des_courriers que le système intégrerait. Bien sur, on doit pouvoir aussi définir des pages personnels via son répertoire squelette.
De même, rien n'interdit d'envisager des pages sépcifiques, par exemple pour une rubrique forum. Pour cela je renvoie à la notion de page décrite dans le projet du noisetier. La manière de les déclarer y est probablement pas très bonne. Par contre, il me semble que le concept mérite réflexion.
Dernier point, qui est probablement un point de détail. Il me semble qu'il n'est pas possible d'afficher avec ACS une même noisette à deux endroits du site mais avec deux configurations différentes. Cela peut certes sembler mineur, mais un système le plus générique possible devrait il permettre une double installation d'une même noisette ? (besoin qui peut se faire sentir).
Voilà, je sais, vous allez dire que je suis bavard et que je ne code pas beaucoup. Vous avez raison. Reste que je suis impressionné par le travail réalisé par ACS, bien qu'il me semble qu'il y ait encore un peu de chemin à parcourir vers le système le plus générique possible d'une gestion du contenus totalement sous forme de noisette.
J'espère au moins que ces différents éléments alimenteront le débat. Il s'agit essentiellement d'une discussion sur les concepts et fonctionnalités que devraient intégrer un tel outil dans l'idéal, non d'un questionnement sur la manière manière de coder tout cela.
Bien cordialement.
Joseph
