[spip-dev] Pour SPIP 2.2 à Condition que... ?

La 2.1 est sortie.

Le plugin Bonux n'ajoute plus ses styles sauf si on le demande explicitement.

À la louche, 99% des plugins qui nécessitent Bonux (environ 45), le font pour avoir accès aux boucles POUR et CONDITION.

Emmanuel, peux-tu expliquer ce qui empêche d'ajouter maintenant ces boucles au noyau pour la prochaine version ? La manière dont c'est fait (des faux serveurs SQL) ? Et dans le même temps, comment penses-tu qu'il faudrait le faire proprement, si tu as une idée ?

Ce plugin devait être quelque chose de *très* temporaire parce qu'on avait pas le temps de réfléchir à telle et telle chose pour la grosse 2.0. Mais ça fait maintenant si longtemps !... Et Bonux est toujours là... de plus en plus nécessité...

Je suis pour vider Bonux de sa subtantifique moelle.

Salut à tous,

Une piste : ne pourrait-on pas généraliser les librairies ?

De nombreux plugins notés en dépendance dans d'autres plugins devraient à mon sens passer en librairies partagées et téléchargées de façon transparente pour le webmestre. Exemple : Bonux, CFG, saisies, etc.

Bien sûr cela impliquerait également un système de gestion des versions et des mises à jours. A voir comment simplifier tout ça et stabiliser une API simple de gestion des plugins/extensions/librairies...

Pat

Ces plugins n'ont rien de différents des autres plugins : il faut surtout une interface d'installation qui sache installer automatiquement les dépendances, d'un coup (après avoir demander confirmation quand même).

Si un plugin nécessite cinq autres choses, peu importe que ce soit lib externes ou plugins SPIP, alors on demande une confirmation ("Voulez-vous que SPIP installe les dépendances pour vous ?") et hop c'est parti ça installe et active tout sans plus rien demander.

Mais ça n'a rien à voir avec ma question. :slight_smile:
Et c'est un chantier déjà en cours, par exemple avec STEP.

La politique de développeemnt depuis la 2.0 vise à l'allégement du noyau, considérant à juste titre que l'interface avec le système de plugins est suffisamment au point pour que ceux qui ne veulent pas de certaines fonctionnalités ne se voient pas imposer un noyau inutilement lourd. Ce serait donc plutôt à toi d'expliquer pourquoi tu veux opérer un virage à 180° avec la politique suivie depuis bientôt 2 ans. Je rappelle en outre que la seule fois où il m'a semblé avoir besoin de ces constructions, j'en ai été empêché par un bug d'implémentation que Cédric a reconnu ne pas pouvoir corriger fiablement.

Par ailleurs, plutôt que d'utiliser une louche, il vaut mieux utiliser le génie qui tourne en permanence sur spipnet pour collecter des infos sur les sites recensés par la liste "Des sites sous SPIP". Sa dernière livraison remonte à hier soir, et concerne 11502 sites. Il signale que 3583 sites ont activité au moins un plugin, et voici la liste des plugins utilisés par au moins 500 sites:

cfg 1943
couteau_suisse 1379
thickbox1 1149
spip_bonux 1030
crayons 832
spiplistes 758
barretypoenrichie 746
forms 739
player 714
agenda 642
accesrestreint 565

Pour ceux que ça intéresse (et qui ont un compte sur spipnet), la suite ici:
http://www.spip.net/ecrire/?exec=statistiques_referers&jour=debut

Ces chiffres indiquent que moins d'un tiers des sites sous SPIP ont besoin d'un plugin, et Bonux ne saurait prétendre à intégrer le noyau qu'après intégration de cfg, couteau_suisse et thickbox1. Est-ce bien raisonnable ?

Committo,Ergo:Sum

C'est à peine de mauvaise foi, ça... :slight_smile:

Tu sais bien que c'est une analyse quantitative et pas qualitative. Tout seul ça ne veut rien dire.

Il faut déjà séparer les plugins suivant les <categorie> (un nouveau truc cool) : on ne peut pas mettre sur le même plan des plugins qui offrent des fonctionnalités pour l'utilisateur final (un nouvel objet éditorial par ex), des fonctionnalités pour le graphiste ou intégrateur (thickbox), des outils pour les développeurs d'autres plugins (CFG, Bonux, Saisies).

Thèse principale : ce n'est pas parce que le but est d'alléger le noyau, que rien ne peut y entrer. Il ne me semble pas avoir lu ça quelque part !...

À mon sens, le but du noyau est *justement* de fournir un ensemble d'outils, d'API, etc, pour pouvoir ensuite ajouter des fonctionnalités grâces aux plugins.

Alors bien sûr, il existe des API qui ne sont réservées qu'à un domaine. Par exemple fournir un plugin qui permet d'utiliser des choses de Google (comme le plugin Google Map API), oui ça reste évidemment un plugin.

Mais des choses comme :
- boucler sur un tableau (boucle POUR)
- pouvoir faire des boucles à l'intérieur d'une condition (boucle CONDITION)
ne sont-ce pas des besoins totalement *génériques* ?

Moi ça me paraissait évident que les besoins génériques, les trucs de base en programmation comme boucler sur un tableau, ça devait faire partie du noyau, quelque soit les statistiques.

(Et j'ajoute que mes stats avaient beau être à la louche, elles sont vraies : va voir les 45 plugins dont je parle, ils utilisent tous Bonux pour avoir accès à la boucle POUR ou la boucle CONDITION.
Je ne parlais pas des statistiques des sites finaux : ça ne fait pas partie des arguments, pour moi. Je parlais de l'utilisation des plugins entre eux, avec les <necessite>.)

Sur le principe, je ne vois donc toujours pas ce qui embête. Après qu'il y ait des problèmes dans l'implémentation actuelle, ça ok. Mais alors quoi et comment y remédier ?

Mais alors

quoi et comment y remédier ?

Il a été question de BOUCLE_x(php:TABLEAU) je crois, ou on indiquerait clairement le connecteur à utiliser, qui n'est pas de type SQL, si j'ai bon souvenir.

2010/4/19 Matthieu Marcillaud <marcimat@rezo.net>

Ces chiffres indiquent que moins d'un tiers des sites sous SPIP ont besoin d'un plugin, et Bonux ne saurait prétendre à intégrer le noyau qu'après intégration de cfg, couteau_suisse et thickbox1. Est-ce bien raisonnable ?

C'est à peine de mauvaise foi, ça... :slight_smile:

La mauvaise foi est de s'appuyer sur des chiffres quand ça vous arrange, et de nier l'intérêt de certains chiffres quand ils vous dérangent.

c'est une analyse quantitative et pas qualitative.

Alors pourquoi as-tu commencé par parler chiffres ?

À mon sens, le but du noyau est *justement* de fournir un ensemble d'outils, d'API, etc, pour pouvoir ensuite ajouter des fonctionnalités grâces aux plugins.

Un "noyau" n'est pas un "ensemble", c'est un organisme cohérent. Boucler sur autre chose qu'une table introduit une incohérence, et augmente le temps d'apprentissage du noyau. On ne peut plus dire "le langage des squelettes s'apprend très vite".

Moi ça me paraissait évident

Chaque fois que qq parle d'évidence, la seule évidence qu'il prouve est qu'il refuse de considérer que les autres peuvent avoir des référents culturels différents des siens. Les politiciens adorent cette réthorique qui permet de faire croire que leur volonté n'a pas à être débatue.

que les besoins génériques, les trucs de base en programmation

mais justement le langage des squelettes n'est pas un langage de programmation, et si on franchit cette ligne jaune, il doit alors se comparer à d'autres langages de programmation, notamment PHP, et alors SPIP est perdant car lacunaire et incohérent.

Sur le principe, je ne vois donc toujours pas ce qui embête.

C'est bien dommage.

Après qu'il y ait des problèmes dans l'implémentation actuelle, ça ok. Mais alors quoi et comment y remédier ?

C'est à ceux qui pensent que ces constructions foireuses sont viables de le faire, pas à moi.

Committo,Ergo:Sum

Pourquoi pas oui, sauf que je ne parlais pas de SPIP 5, mais de SPIP 2.2.

C'est ce dont je prend conscience,
à force de patiner à essayer de faire des choses avec spip
au lieu de les faire "simplement" et surtout "directement" en php.

Mais dans ce cas ESJ, comment doit être comprise et pratiquée
l'expression "SPIP comme framework" ?

JLuc

* Committo,Ergo:sum tapuscrivait, le 19/04/2010 16:30:

mais justement le langage des squelettes n'est pas un langage de programmation

Aujourd'hui, le langage de SPIP permet de faire :
- des Boucles, mais uniquement sur le résultat de requêtes SQL
- des conditions :
  - 1) dans une boucle, si la boucle est vide
  - 2) dans une balise, si la balise est vide (mais sans pouvoir mettre une boucle dans le résultat)
- des affectations de variables (#SET)
- des affichage d'une variagle (#GET ou #ENV selon les cas)

La proposition d'évolution de la syntaxe du langage que tu as faites à Avignon permettait de régler la limitation de 2) (ce qui règlerait la question du besoin d'une syntaxe supplémentaire pour les conditions)

Reste de pouvoir faire une boucle sur autre chose qu'une requête SQL.

> et si on franchit cette ligne jaune, il doit alors se comparer à
> d'autres langages de programmation, notamment PHP, et alors SPIP est
> perdant car lacunaire et incohérent.
J'avoue mon ignorance : en quoi serait-ce lacunaire ?
Et incohérent ?

-- RealET

Je renvoie à la présentation de SPIP 2.0:
http://www.spip.net/fr_article3784.html
qui précisait bien qu'il y a plusieurs niveaux d'utilisation de SPIP.
Le noyau doit rester un langage accessible aux non programmeurs,
a fortiori si les extensions proposées sont lacunaires et bugées.

Committo,Ergo:Sum

Oui tout à fait, je reconnais bien volontier que la construction actuelle n'est ni satisfaisante au niveau de la syntaxe, ni au niveau de sa fiabilité.
Je ne l'ai retenue que parce qu'elle est réalisable en plugin simplement avec un ratio (energie dépensée)/bénéfices tout de même satisfaisant.
Il est clair qu'intégrer cette implémentation dans le core n'est pas satisfaisant ni défendable.

Introduire cette fonctionnalité avec une syntaxe satisfaisante ne peut se faire que par évolution du phraseur (a minima), ce qui est hors de question dans un plugin, en dehors du core, sauf à dépenser une énergie folle à suivre les évolutions du core.

Dans la pratique, cette évolution ne pourra donc se faire que par évolution du core, et il est logique qu'Emmanuel n'en ayant ni l'usage ni le souhait il n'ait pas envie de prendre à sa charge cette tâche ingrate.
La solution est donc simplement de proposer un patch efficace, fiable, et correct.
Et dans l'attente Bonux perdurera comme il est.

Sur le fond de la question (SPIP est-il un langage de programmation ? doit il avoir une structure itérative ?), j'avais bookmarqué un intéressant article sur le sujet
http://fabien.potencier.org/article/34/templating-engines-in-php
qui m'avait fait penser que SPIP se positionne plutôt comme un langage de template, et réponds pour une grande part aux problèmes et besoins énoncés assez justement par cet article (l'héritage étant dans le cas de SPIP remplacé par la surcharge)

Je note que la plupart (tous?) des moteurs de templating ont une structure itérative, simplement parce que ça répond à un besoin pratique.
Cédric

Le compilateur est-il prévu pour être extensible du point de vu des expression pseudo-XML des boucles ?
Parce que si un système permettait d’ajouter des instructions par des plugins aussi facilement que des balises ou des filtres, ça résoudrait plein de problèmes sans nuire à la “pureté” du core, et il n’y aurait plus qu’à creuser le concept de lib et dépendance comme il a été dit.

Bon, mes (lacunaires) connaissances en compilation me font craindre une complexité effroyable pour une telle fonctionnalité…
C’est bien ça ? :slight_smile:

A bientôt
Simon

[...]

D'accord avec ton mail Cédric, sauf sur ce point-ci:

Introduire cette fonctionnalité avec une syntaxe satisfaisante ne peut se faire que par évolution du phraseur (a minima), ce qui est hors de question dans un plugin, en dehors du core, sauf à dépenser une énergie folle à suivre les évolutions du core.

La notion de macro en programmation est justement là pour changer la syntaxe sans toucher au noyau. C'est ce qui se passe pour C et son préprocesseur, ou le couple TeX/LaTeX, même si pour SPIP le rapport est inversé: c'est le noyau qui est pour les non-programmeurs et les compléments (ici, certains plugins) pour les programmeurs.

Le nouveau cadre syntaxique que j'avais esquissé à Avignon était justement pour faciliter l'écriture de plugin pouvant beaucoup changer les fonctionnalités du noyau sans plus intervenir dessus. Mais c'est clairement pas SPIP 2.2.

Committo,Ergo:Sum

La mauvaise foi est de s'appuyer sur des chiffres quand ça vous arrange, et de nier l'intérêt de certains chiffres quand ils vous dérangent.

Je ne sais pas si on s'est mal compris, mais en relisant mon premier message ça me parait toujours clair : à aucun moment je n'ai dit "beaucoup de plugins / beaucoup de sites utilisent Bonux et donc il faut l'intégrer au noyau".

J'ai dit très exactement que *ceux* des plugins qui utilisent Bonux, le font tous pour avoir accès aux boucles POUR et CONDITION. Juste pour dire que Bonux, qui est au départ un agglomérat de choses qui auraient pu être dans SPIP 2.0 mais qui n'étaient pas au point au bon moment, est essentiellement utilisé pour ces deux fonctionnalités. Ma réflexion partant du fait que je vois de plus en plus de plugins le nécessiter alors que ces boucles ajoutent des choses que je trouve basiques lorsqu'on programme (je reviens sur ce mot plus loin).

Alors pourquoi as-tu commencé par parler chiffres ?

Cf la phrase commençant par "Juste", précédemment.

Un "noyau" n'est pas un "ensemble", c'est un organisme cohérent.

Au sens strict oui. Mais le noyau de SPIP, même sans parler des objets éditoriaux, reste un ensemble : un compilateur de squelette, un API de serveur SQL virtualisé, une API d'autorisations, une API pour faire des formulaires, un agglomérat de fonctions "utils", une API pour générer des URLs différentes, etc.

Moi j'entends "noyau" comme "une base simple à comprendre et solide sur laquelle greffer des extensions".

Oui, on peut toujours trouver un noyau plus petit, plus pur.

Boucler sur autre chose qu'une table introduit une incohérence, et augmente le temps d'apprentissage du noyau. On ne peut plus dire "le langage des squelettes s'apprend très vite".

Pourquoi une incohérence ? Par rapport à ton système de valeurs ? :slight_smile:
Si tu penses que le centre du centre du centre de SPIP ne devrait être qu'un langage permettant de lire une base de données et d'afficher ses champs, effectivement.

Mais puisque tu aimes expliquer le sens des mots, je veux bien apprendre (vu que je ne connais pas les grands concepts de théorie du langage qu'il y a derrière ) : en quoi le mot "boucler" indique que l'on boucle sur une table de base de données ?

En quoi boucler sur une table est différent de boucler sur le contenu d'un tableau (surtout que par derrière, le contenu de la table est d'abord transformé en tableau) ? Pour l'instant, pour moi, le terme "boucler" ou "faire une boucle" veut dire : *parcourir un à un une liste d'élément*. Et ça tombe bien : c'est ce même sens qu'utilise la plupart des autres "langages" (entre guillemet parce que je ne parle pas que des langages de programmation, mais aussi tous les simples langages ou syntaxes de templates, qui proposent tous un moyen de boucler sur un tableau).
Si on invente un sens à "boucler" qui est uniquement propre à SPIP, c'est justement là qu'on ne peut pas dire que c'est facile à apprendre.

Moi ça me paraissait évident

Chaque fois que qq parle d'évidence, la seule évidence qu'il prouve est qu'il refuse de considérer que les autres peuvent avoir des référents culturels différents des siens. Les politiciens adorent cette réthorique qui permet de faire croire que leur volonté n'a pas à être débatue.

Et inversement, ne jamais trouver qu'il y a des choses communes à *tous*, ouvre la porte à un déconstructionnisme permanent. :slight_smile:

mais justement le langage des squelettes n'est pas un langage de programmation, et si on franchit cette ligne jaune, il doit alors se comparer à d'autres langages de programmation, notamment PHP, et alors SPIP est perdant car lacunaire et incohérent.

Ça ne me viendrait pas à l'idée de faire de SPIP un vrai langage de programmation. Il n'en a jamais été question je crois.

Au départ le langage des squelettes est un langage de ... squelettes. De template quoi. Ce qui n'indique toujours pas qu'il ne doit afficher que des choses venant d'une base de données !...

C'est pas tout blanc ou tout noir, soit un langage de programmation complet et cohérent, soit un langage qui ne fait qu'aider à afficher une base de données...

Tous les langages de templates permettent de faire des conditions et de boucler sur des liste d'éléments. (Non le "tous" n'est pas dit à la louche : Web template system - Wikipedia .)

C'est bien dommage.

C'est pas très pédagogue comme réponse.

C'est à ceux qui pensent que ces constructions foireuses sont viables de le faire, pas à moi.

Expliquer comme résoudre, c'est aux autres oui. Mais expliquer ce qui est foireux, c'est à ceux qui trouvent que c'est foireux, non ?

Bon alors Cédric ? :slight_smile:

Et sinon dans un premier temps, est-il imaginable de :
- améliorer l'implémentation puisqu'il parait que c'est foireux
- en faire une extension du core pour justement ne pas le mettre dans le noyau mais qu'il soit dans la distribution de base quand même ?

Même si ce n'est plus mon activité principale,
je ne peux pas me considérer comme non programmeur.

Je trouve que le compilateur n'est pas exempt non plus de ...
spécifications capricieuses, dés qu'on fait de la "programmation" avec spip :
. des syntaxes différentes selon le contexte
. une gestion circonstancielle des erreurs de code par le compilateur
(amélioré avec la V2.1 ?)
Je n'étais pas très favorable à un changement de syntaxe,
mais si XML amenait une syntaxe facilement descriptible dans son entièreté
(ce qui n'est pas le cas actuellement) et implémentée avec rigueur,
ce serait un plus appréciable.

JL

en quoi le mot "boucler" indique que l'on boucle
sur une table de base de données ?

peut-être le terme BOUCLE a-t'il été historiquement mal choisi et ça
se peut se comprendre en revenant aux années 2000 et à la volonté des
inventeurs de spip de masquer la complexité de la machinerie
sous-jacente à la production d'un site web.
peut-être REQUETE aurait-il été plus 'juste'...

Pour l'instant, pour moi, le terme
"boucler" ou "faire une boucle" veut dire : *parcourir un à un une liste
d'élément*.

non. une boucle n'est pas qu'un dévidoir.
c'est avant tout un générateur de requête sql ;
ensuite, et seulement ensuite, c'est un afficheur de résultats.

Si on invente un sens à "boucler" qui est uniquement propre à SPIP,
c'est justement là qu'on ne peut pas dire que c'est facile à apprendre.

bof.
pas plus difficile à comprendre que le fait que #GET n'a rien, mais
alors rien, à voir avec le $_GET du php

il y a bien un moment où il faut établir (puis se tenir à) des
conventions de langage. sans oublier que l'histoire, l'usage, y jouent
aussi leur rôle.

on a déjà le cas des #BALISES où rien dans leur écriture ne différencie
les statiques des dynamiques/calculées (comment expliquer, autrement
qu'en se basant sur les 'conventions' -historiques en l'occurence- que
pour afficher le champ 'login_public' d'une table externe il faille
utiliser #CHAMP_SQL{login_public} et pas #LOGIN_PUBLIC ? pareil pour un champ nommé 'points'...)
"il y a." et "c'est comme ça."