r14588 - in spip: ecrire ecrire/action ecrire/base ecrire/exec ecrire/inc ecrire/maj ecrire/public prive/modeles squelettes-dist

Notifications Commit Core
1

Author: esj@rezo.net
Date: 2009-10-08 14:39:58 +0200 (jeu, 08 oct 2009)
New Revision: 14588

Log:
Incompatibilé forte: Oracle ayant {{{mode}}} comme mot-clé réservé, il ne peut être utilisé dans un champ de table. En conséquence, renommage sous le nom {{{genre}}} du champ {{{mode}}} de la table {{{spip_documents}}}, avec répercussion sur les squelettes et les scripts utilisant cette table. La globale {{{exceptions_des_tables}}} aurait pu éviter l'incompatibilité pour certains squelettes, mais pas pour ceux ayant {{{mode}}} dans leur critères, ni pour les scrips effectuant des requêtes SQL explicites sur cette table.

A noter que la fonction {{{inc_joindre}}} continue à attendre un tableau dont un des index est {{{mode}}}: c'est sans doute étrange mais ça fait du travail en moins. Si on y tient absolument, on pourra aussi le changer: c'est le ''travailler plus pour nommer plus''.

Modified:
   spip/ecrire/action/changer_mode_document.php
   spip/ecrire/action/documenter.php
   spip/ecrire/base/serial.php
   spip/ecrire/exec/documents_liste.php
   spip/ecrire/inc/ajouter_documents.php
   spip/ecrire/inc/documenter.php
   spip/ecrire/inc/documents.php
   spip/ecrire/inc/legender.php
   spip/ecrire/inc/session.php
   spip/ecrire/inc_version.php
   spip/ecrire/maj/svn10000.php
   spip/ecrire/public/boucles.php
   spip/ecrire/public/quete.php
   spip/prive/modeles/doc.html
   spip/prive/modeles/img.html
   spip/squelettes-dist/inc-documents.html
   spip/squelettes-dist/inc-rss-item.html
   spip/squelettes-dist/rubrique.html

Details: http://trac.rezo.net/trac/spip/changeset/14588

2

[Je réponds à la team, ça me semble préférable]

Le 8 oct. 09 à 15:34, Fil a écrit :

et qu'il faudrait de toutes façons reconcevoir ce truc là.

Oui c'est la reconception façon bulldozer : je casse tout, à vous de réparer.

J'ai cassé le moins possible, et en particulier pas le core qui offre les mêmes fonctionnalités qu'avant. Je n'en dirai pas autant du bandeau actuel, qui ne permet plus de déclarer des mots-clés et des sites dans une version neuve. J'aimerais que tu m'expliques pourquoi tu es moins choqué par l'un que par l'autre, alors qu'on voit bien lequel des deux gênera l'utilisateur moyen et pas l'autre.

Dans ces conditions, on
peut abandonner le développement soi-disant "collaboratif".

En ce qui concerne le core, le taux d'activité suggère que c'est malheusement déjà le cas. Par aillerurs quand, à l'inverse d'aujourd'hui, j'ai pris la peine d'annoncer ce que je souhaiterais faire sur le long terme en matière de syntaxe des squelettes tu as dit "NIET" (sic) sans même vouloir entendre mes arguments et mes propositions. Alors de nous deux, qui a abandonné le développement collaboratif sur le core, quelle que soit la manière dont on lui propose de travailler ?

Mais puisqu'il faut annoncer la suite des contrariétés, j'ai gardé le plus
beau pour la fin: "date" est un mot réservé.

tu aurais très bien pu trouver un mécanisme d'exception pour Oracle.

Même en admettant que ce soit vrai, ce qui n'est pas sûr, un telle méthode de développement se discute. Si on empile les exceptions le système devient illisible. Je prétends qu'aujourd'hui SPIP est devenu une usine à gaz que ne peut pénétrer que ceux qui le connaissent depuis plusieurs années, et donc que l'on va vers un dépérissement de la communauté: spip-zone est actif, mais c'est toujours les 50 mêmes. Est-ce que vraiment cet aspect des choses te laisse de marbre ?

Emmanuel

3

Bonjour Emmanuel,
C'est plus que fâcheux.

Ca fait des mois qu'on reflechit sur l'évolution des documents et comment s'en tirer pour avoir quelque chose de simple à comprendre et à utiliser sans casser la compatibilité.
Du même coup, ça forke aussi toute la gestion des documents que j'ai refaite de A à Z dans un plugin, et qui est en maturation sur la zone avant intégration, encore une fois pour faire les choses en douceur sans rien casser.

Et là tout est cassé d'un coup sans même en avoir parlé ensemble.
Moralité, quand on se donne la peine de pas commit dans le lard sur la branche dev et de préparer le terrain à côté, c'est pour sa pomme et on est bon pour se refaire tout le retard et les merge.

Ce commit est à plus d'un titre très peu légitime.

Plus généralement, si le support d'Oracle doit nous amener à casser plein de compatibilités, on peut très sérieusement se poser l'intérêt.
Pour satisfaire deux ou trois utilisateurs, on va faire perdre des heures à des centaines ou des milliers d'autres.

Car qui sérieusement peut dire qu'il connait quelqu'un qui utilisera SPIP quand il supportera Oracle ?

Quand par ailleurs, je vois que tu ne réponds toujours pas sur ce que l'on fait la boucle POUR (ou une autre structure itérative équivalente) qui pourtant est utilisée et réclamée par plein de monde, je me demande dans quelle direction on va là.

Dans le mur ?

Cédric

Le 8 oct. 2009 à 14:39, esj@rezo.net a écrit :

Author: esj@rezo.net
Date: 2009-10-08 14:39:58 +0200 (jeu, 08 oct 2009)
New Revision: 14588

Log:
Incompatibilé forte: Oracle ayant {{{mode}}} comme mot-clé réservé, il ne peut être utilisé dans un champ de table. En conséquence, renommage sous le nom {{{genre}}} du champ {{{mode}}} de la table {{{spip_documents}}}, avec répercussion sur les squelettes et les scripts utilisant cette table. La globale {{{exceptions_des_tables}}} aurait pu éviter l'incompatibilité pour certains squelettes, mais pas pour ceux ayant {{{mode}}} dans leur critères, ni pour les scrips effectuant des requêtes SQL explicites sur cette table.

A noter que la fonction {{{inc_joindre}}} continue à attendre un tableau dont un des index est {{{mode}}}: c'est sans doute étrange mais ça fait du travail en moins. Si on y tient absolument, on pourra aussi le changer: c'est le ''travailler plus pour nommer plus''.

Modified:
  spip/ecrire/action/changer_mode_document.php
  spip/ecrire/action/documenter.php
  spip/ecrire/base/serial.php
  spip/ecrire/exec/documents_liste.php
  spip/ecrire/inc/ajouter_documents.php
  spip/ecrire/inc/documenter.php
  spip/ecrire/inc/documents.php
  spip/ecrire/inc/legender.php
  spip/ecrire/inc/session.php
  spip/ecrire/inc_version.php
  spip/ecrire/maj/svn10000.php
  spip/ecrire/public/boucles.php
  spip/ecrire/public/quete.php
  spip/prive/modeles/doc.html
  spip/prive/modeles/img.html
  spip/squelettes-dist/inc-documents.html
  spip/squelettes-dist/inc-rss-item.html
  spip/squelettes-dist/rubrique.html

Details: http://trac.rezo.net/trac/spip/changeset/14588

_______________________________________________
spip-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-commit
dev: http://trac.rezo.net/trac/spip/

4

J'ai cassé le moins possible, et en particulier pas le core qui offre les
mêmes fonctionnalités qu'avant.

Tu es allé jusqu'à changer modeles/ rendant non fonctionnels les
modèles modifiés par les uns et les autres. Par contre, tu n'avais pas
répondu à mon email proposant une solution au problème des documents.
C'est ça que je critique : tu avances seul, avec des oeilleres, et
quand on te le fait remarquer on se fait engueuler !

Je n'en dirai pas autant du bandeau actuel,
qui ne permet plus de déclarer des mots-clés et des sites dans une version
neuve. J'aimerais que tu m'expliques pourquoi tu es moins choqué par l'un
que par l'autre, alors qu'on voit bien lequel des deux gênera l'utilisateur
moyen et pas l'autre.

Je suis tout à fait désespéré par le bando actuel, mais c'est à ton
mail que je répondais. Sur le bando il y a déjà quatre trolls en cours
(and counting), je n'ai rien de plus à ajouter.

Quoi qu'il en soit ces méthodes d'argumentations me sont pénibles : tu
ne peux pas t'appuyer sur un truc fouareux pour défendre un autre truc
fouareux. Chaque chose doit se discuter pour elle-même.

En ce qui concerne le core, le taux d'activité suggère que c'est
malheusement déjà le cas.

Le fait que certains soient plus ou moins actifs à certains moments
n'est pas vraiment indicatif. Mais en effet je t'accorde qu' il y a
des raisons à cela, y compris, mais pas seulement, celles que tu
mentionnes.

Par aillerurs quand, à l'inverse d'aujourd'hui,
j'ai pris la peine d'annoncer ce que je souhaiterais faire sur le long terme
en matière de syntaxe des squelettes tu as dit "NIET" (sic) sans même
vouloir entendre mes arguments et mes propositions. Alors de nous deux, qui
a abandonné le développement collaboratif sur le core, quelle que soit la
manière dont on lui propose de travailler ?

J'ai entendu tes arguments, notamment celui que tu as modifié en cours
de discussion pour rendre l'opération acceptable : ie que la syntaxe
proposée serait proposée *en plus* de l'existante. Elle suffit à mon
bonheur.

Mais puisqu'il faut annoncer la suite des contrariétés, j'ai gardé le
plus beau pour la fin: "date" est un mot réservé.

Soyons précis : réservé PAR ORACLE.

tu aurais très bien pu trouver un mécanisme d'exception pour Oracle.

Même en admettant que ce soit vrai, ce qui n'est pas sûr, un telle méthode
de développement se discute. Si on empile les exceptions le système devient
illisible.

Oui c'est exact ; mais en l'occurrence, face un bug à contourner sur
l'un des SGBD du marché, tu préfères casser la compatibilité
ascendante que de contourner le bug. C'est ça qui, je répète, devrait
se *discuter*.

Je prétends qu'aujourd'hui SPIP est devenu une usine à gaz que ne
peut pénétrer que ceux qui le connaissent depuis plusieurs années, et donc
que l'on va vers un dépérissement de la communauté: spip-zone est actif,
mais c'est toujours les 50 mêmes. Est-ce que vraiment cet aspect des choses
te laisse de marbre ?

Non, et tu as tout à fait raison sur ce point. Je ne crois pas
cependant que ça justifie de casser la compatibilité ascendante sauf
quand c'est vraiment indispensable.

Cela dit ma critique portait sur un point précis : la gestion des
documents pose des problèmes depuis des années, on cherche des
solutions, et tu arrives là-dessus comme un éléphant, sur une question
accessoire (qui te dit que "genre" ne sera pas réservé en protoSQL
3.78 ?), sans tenir aucun compte de l'état des lieux.

Mais en fait on a déjà eu cette discussion, et ça me lasse.

-- Fil

5

Je croyais que Subversion était un outil de gestion de versions, je découvre que c'est en fait un outil pour délier les langues. C'est ainsi que j'apprends enfin que le conflit silencieux dont il a été question il y a quelques temps concerne l'intégration de la boucle Pour dans le core. Rien que pour ça et d'autres du meme genre, je ne regrette pas 14588 même s'il représente plusieurs heures de travail qui risquent de passer à la poubelle.

Alors au-delà de ces lignes de code auxquelles je ne tiens pas plus que ça, parlons des pbs de fond.

Je plaide coupable d'abord sur cette histoire de mail de Fil laissé sans réponse, je n'en ai AUCUN souvenir.
Il ne faut pas hésiter à me relancer dans ces cas-là, j'ai simplement trop de sujet de préoccupations.

Maintenant, ce que je comprends de la situation générale, c'est que les engueulades issues des dépots sur le code ont conduit à ce que des dépots qui auraient dû y atterrir ont pris le maquis sur spip-zone. La fuite n'est jamais une solution, le conflit finit donc par réapparaître, et on revendique le long travail rédactionnel pendant la période d'exil à Médine pour dire que ces écritures sont considérés comme saintes par la communauté des croyants, qu'on chiffre allègrement à des milliers. Je suis désolé, ce ne sont pas des méthodes de travail et d'argumentation, a fortiori quand sur d'autres points -- le bandeau -- on se gêne pas pour continuer à piloner la Mecque.

Autre point qui n'est pas complètement sans rapport: je n'ai pas "modifié un argument en cours de discussion pour rendre acceptable l'arrivée de la nouvelle syntaxe". Cette fonctionnalité étant là depuis la 1.8, elle n'est pas arrivée au cours de la discussion, et il est bien clair dans mon esprit que le but visé est que le core ne contienne plus de squelettes en ancienne syntaxe, même s'il continuera à les supporter. Il y a autour de ça un pb plus général et important: SPIP est-il un plat de nouilles où chacun cuisine sa nouille de son côté en se disant que le plat résultant devrait être mangeable, ou bien est-il un véritable projet collaboratif où la liste des ingrédients est décidée en commun, seule la pluche étant individuelle vu la taille moyenne des légumes ?

Je suis vraiment surpris, Cédric, que tu puisses autant travailler à la diminution du core et maintenant vouloir lui rajouter des choses. Je n'ai pas lancé la discussion sur la syntaxe par suite d'une nouvelle lubie perso (c'est si vieux comme sujet), mais bien comme une première étape vers une conception bien fichue et minimale du nouveau noyau de SPIP. Car pour moi, ce qui "va dans le mur" c'est la méthode de travail reposant sur une suite de référendums d'initiative populaire. Il *faut* que nous élaborions en une fois à quoi ressemblera SPIP3, sinon les problèmes d'aujourd'hui ne feront qu'empirer.

Emmanuel

6

Je croyais que Subversion était un outil de gestion de versions, je découvre
que c'est en fait un outil pour délier les langues.

On peut le voir autrement : faute de temps tu ne lis pas les mails,
puis tu commites "dans le tas", et quand on réagit... tu nous accuses
d'être restés silencieux. Tu découvres donc que le troll et la
gueulante sont des outils destinés à te faire prendre conscience que
tu as raté ce qu'on a déjà dit, plus calmement, auparavant.

C'est ainsi que
j'apprends enfin que le conflit silencieux dont il a été question il y a
quelques temps concerne l'intégration de la boucle Pour dans le core.

Ce n'est pas un secret que tu as cassé cette boucle à plusieurs
reprises, et qu'on te l'a signalé, à plusieurs reprises.

Rien que pour ça et d'autres du meme genre, je ne regrette pas 14588 même s'il
représente plusieurs heures de travail qui risquent de passer à la poubelle.

Je n'ai rien dit sur le fond de ta modif, seulement sur la méthode
(oeillères) et le résultat (cassage de compat).

Alors au-delà de ces lignes de code auxquelles je ne tiens pas plus que ça,
parlons des pbs de fond.

OK

Je plaide coupable d'abord sur cette histoire de mail de Fil laissé sans
réponse, je n'en ai AUCUN souvenir.
Il ne faut pas hésiter à me relancer dans ces cas-là, j'ai simplement trop
de sujet de préoccupations.

Tu veux dire ajouter des emails aux emails ? Mon message concernait
les documents, et ne te concernait donc pas personnellement, puisque
tu n'avais pas signalé un intérêt particulier à ce propos ; c'était
d'ailleurs loin d'être le seul à aborder la question des documents et
du champ problématique "mode". Je ne vois donc pas pourquoi j'aurais
dû te relancer. En revanche quand tu exploses la table documents sans
regarder ce qui s'en dit à droite et à gauche, et ce, depuis deux ans,
ne t'étonne pas que ça coince.

Maintenant, ce que je comprends de la situation générale, c'est que les
engueulades issues des dépots sur le code ont conduit à ce que des dépots
qui auraient dû y atterrir ont pris le maquis sur spip-zone. La fuite n'est
jamais une solution, le conflit finit donc par réapparaître, et on

Pas faux. Il pourrait réapparaître dans un mode plus apaisé, c'est ce
qu'on souhaite en général quand on reporte à plus tard.

revendique le long travail rédactionnel pendant la période d'exil à Médine
pour dire que ces écritures sont considérés comme saintes par la communauté
des croyants, qu'on chiffre allègrement à des milliers. Je suis désolé, ce
ne sont pas des méthodes de travail et d'argumentation, a fortiori quand sur
d'autres points -- le bandeau -- on se gêne pas pour continuer à piloner la
Mecque.

Je n'ai rien compris à ta métaphore, si ce n'est que tu essaies de
renverser l'accusation sur les méthodes d'argumentation. Je maintiens
ma critique à ce propos.

Autre point qui n'est pas complètement sans rapport: je n'ai pas "modifié un
argument en cours de discussion pour rendre acceptable l'arrivée de la
nouvelle syntaxe". Cette fonctionnalité étant là depuis la 1.8, elle n'est
pas arrivée au cours de la discussion, et il est bien clair dans mon esprit
que le but visé est que le core ne contienne plus de squelettes en ancienne
syntaxe, même s'il continuera à les supporter.

J'adore qu'on ose encore parler de "nouvelle syntaxe" pour un truc qui
n'existe pas, et d'"ancienne syntaxe" pour la syntaxe actuelle. Sur le
fond, si une nouvelle syntaxe émerge et qu'elle convainc, je pense
qu'on finira par y adhérer, car tous les développements en seront
facilités. Si ce n'est pas le cas, la "nouvelle syntaxe" finira à la
poubelle, et la syntaxe actuelle restera celle de SPIP. Que tu te
places dans une perspective de succès est bien normal (encore heureux
!), mais tu ne l'obtiendras pas sous forme de décision administrative
ex ante.

(je zappe la nouille)

Il *faut* que nous élaborions en une
fois à quoi ressemblera SPIP3,

On a décidé très collectivement de faire pour SPIP 2.1 de la réduction
sous forme de plugins, et largement commencé ce chantier. Tu parles de
SPIP 3, et là justement, je connais pas... Mais peut-être faut-il
faire plusieurs branches, l'une attaquant la réduction en plugins,
l'autre formulant les nouveaux concepts meta, et peut-être encore une
sur le bando et l'interface. Actuellement en touillant tous dans le
même pot on s'aperçoit qu'on va de clash en clash, que chacun est
bloqué parce que les brouillons des autres l'empêchent d'avancer sur
ses propres chantiers.

Pour prendre un exemple, par rapport à ma propre activité de dev, j'ai
dans l'idée de proposer un nouveau concept de moteur typo/raccourcis,
et je me garde bien de le développer sur le svn de SPIP.

sinon les problèmes d'aujourd'hui ne feront qu'empirer.

ou pas.

-- Fil

7

Le 8 oct. 09 à 21:04, Fil a écrit :

faute de temps tu ne lis pas les mails,
puis tu commites "dans le tas", et quand on réagit... tu nous accuses
d'être restés silencieux.

Mais enfin de quels mails s'agit-il ?

Ce n'est pas un secret que tu as cassé cette boucle à plusieurs
reprises, et qu'on te l'a signalé, à plusieurs reprises.

Mon point de vue est que si cette boucle est aussi fragile,
c'est quil y a un pb de conception soit dans le compilateur soit chez elle.
Et c'est de ça qu'il faudrait parler.

Mon message concernait
les documents, et ne te concernait donc pas personnellement,

Bon, ce n'était pas clair dans ton précédent mail.

puisque tu n'avais pas signalé un intérêt particulier à ce propos ; c'était
d'ailleurs loin d'être le seul à aborder la question des documents et
du champ problématique "mode". Je ne vois donc pas pourquoi j'aurais
dû te relancer. En revanche quand tu exploses la table documents sans
regarder ce qui s'en dit à droite et à gauche, et ce, depuis deux ans,
ne t'étonne pas que ça coince.

Encore une fois, je vais essayer de trouver une solution alternative,
mais franchement si un simple renommage est une explosion,
alors on va manquer de vocabulaire pour des choses autrement plus graves.

Je n'ai rien compris à ta métaphore, si ce n'est que tu essaies de
renverser l'accusation sur les méthodes d'argumentation. Je maintiens
ma critique à ce propos.

Perso quand je ne comprends pas, je demande des explications supplémentaires avant de maintenir ce que je dis.

le but visé est que le core ne contienne plus de squelettes en ancienne

syntaxe, même s'il continuera à les supporter.

mais tu ne l'obtiendras pas sous forme de décision administrative
ex ante.

Non mais enfin je rêve: qu'est-ce qu'il y a d'administratif dans tout ce que j'ai fait à ce propos ?
Si je comprends bien, quand je commite sans prévenir, j'ai des oeillères, mais quand je préviens, je suis un bureaucrate. C'est quoi la bonne méthode ? T'envoyer des patchs et dire qu'il n'y a plus que toi qui a le droit de faire des commit ?

(je zappe la nouille)

Alors toi tu as le droit de zapper la partie la plus importante d'un mail que tu viens de recevoir, mais moi quand j'ai oublié qu'il y a des semaines voire des mois il y a eu des mails qui ont un rapport avec un pb que je rencontre lors d'un portage, j'ai pas le droit. Comme quoi les oeillères, il y en a de bien des formats.

Emmanuel

8

Encore une fois, je vais essayer de trouver une solution alternative,

cool

? T'envoyer des patchs et dire qu'il n'y a plus que toi qui a le droit de
faire des commit ?

C'est bien tenté, de me faire passer pour le fils de Staline et de
Ceaucescu. Cependant c'est bien toi qui as opposé un veto à ma
dernière proposition, et pas l'inverse. Alors hein bon, mollo.

Alors toi tu as le droit de zapper la partie la plus importante d'un mail
que tu viens de recevoir,

Ca ne me paraissait justement pas si important que ça, puisque d'ordre
complètement général, alors que je te parle d'un problème spécifique
et bien circonscrit.

Mais puisque tu le demandes, je ne zappe pas, et voici ce que j'en
pense : ces derniers temps, chacun tire en effet un peu plus de son
côté que d'habitude. Tu es loin d'être le seul dans ce cas, mais tu es
le premier du lot car tu es très actif, et très déterminé ; hé oui, tu
t'exposes.

Ca provoque inévitablement des tensions, ce qui est normal, et n'est
pas un problème en soi ; cependant quand on réagit à cela, ta réponse,
qui consiste à dire (je schématise) "je DOIS casser la compatibilité
parce que le SPIP actuel est pourri à cet égard", est trop
systématique pour ne pas devenir casse-nouille.

Quand tu provoques la moindre incompatibilité ascendante (même si tu
la juges "sans importance"), tu sais pourtant qu'il y a derrière des
tas de gens (non, je n'ai pas dit des milliers) qui rament pour
remettre au carré leurs trucs. Et au bout d'un moment, quand c'est
pour des broutilles ou des bugs, et que c'est fait sans considération
pour le reste, oui ça énerve. D'autant qu'on ne passe pas vraiment nos
journées à la pêche à la mouche.

Je m'autorise à critiquer parce que je fais souvent partie de ces
gens-là, et que j'ai déjà consacré au bas mot des dizaines d'heures à
le faire, en général sans ronchonner. Parce que 1) je voyais l'intérêt
à terme 2) je n'avais pas mieux à proposer 3) tu avais pris le temps
d'expliquer en amont, et tu m'avais convaincu.

Or actuellement tout se passe comme s'il fallait qu'on te suive où que
tu ailles, même quand tu es le seul convaincu, et quel que soit le
prix à payer. Alors bon, me faire traiter de petit chef, tu comprends
que ça m'agace ?

mais moi quand j'ai oublié qu'il y a des semaines
voire des mois il y a eu des mails qui ont un rapport avec un pb que je
rencontre lors d'un portage,

hé bien on te le rappelle ; c'est pas beau ça, le dialogue ? Note bien
que Cédric a eu, en parallèle, la même réaction que moi : de te
signaler le problème. Tu réagis à ton tour en haussant d'un ton, et ça
part en vrille. C'est bien la peine de citer Hannah Arendt.

j'ai pas le droit.

Mais arrête un peu de faire le Calimero, je n'ai pas dit que tu
n'avais pas le *droit* !! Je te dis juste que là il y a un problème à
prendre en considération ! J'ai pas le droit ?

Comme quoi les oeillères, il
y en a de bien des formats.

Un bon mot pour avoir le dernier mot.

-- Fil, qui court se mettre à l'abri dans son bunker

9

Le 8 oct. 2009 à 21:42, Committo,Ergo:sum a écrit :

Ce n'est pas un secret que tu as cassé cette boucle à plusieurs
reprises, et qu'on te l'a signalé, à plusieurs reprises.

Mon point de vue est que si cette boucle est aussi fragile,
c'est quil y a un pb de conception soit dans le compilateur soit chez elle.
Et c'est de ça qu'il faudrait parler.

Bien volontiers.

Le fait est qu'une structure itérative dans les squelettes est grandement utile au portage de nombreux script php sous forme de squelette, ce qui accèlere le développement, la maintenance, et permet potentiellement à des contributeurs ne maitrisant pas php de contribuer au développement de l'interface privée, où d'autres interfaces.

Chaque fois que nous avons évoqué le problème ensemble tu es resté sceptique car tu n'en vois pas l'intérêt par rapport à un filtre php et un foreach dedans (c'est ce que j'ai compris)

La solution actuelle qui est dans Bonux n'a pas une syntaxe idéale car elle a été développée sans toucher au compilateur pour être la plus stable et durable possible (au contraire des anciennes boucles tableau de piif, qui réécrivaient plein de code généré par la boucle, et étaient dures à maintenir).

Plus le temps passe dans cette situation, plus la syntaxe actuelle, non idéale, va s'imposer de fait, et plus il sera compliqué d'en changer. On pourra encore dire à ce moment là que ce truc là est mal foutu/pensé et tout casser. Mais force est de constater que ce serait plus simple de prendre le sujet dès le début pour éviter d'en arriver là.

La boucle a cassé à plusieurs reprises sur des changements non mineurs :
- la suppression du strlower sur les noms de table
- l'ajout d'un pré-requis implicite sur les interface sql dont sql_select devait renvoyer une ressource exclusivement.

Sur le fond, il est certain qu'intégrer la structure itérative au core serait la solution la plus stable et perenne pour tout le monde.

On peut considérer que faire du dev sur la zone est "prendre le maquis".

En l'occurence c'est purement pragmatique :
J'ai proposé la fonctionnalité dans le core.
Elle a été rejetée car pas jugée pas opportune.
Je la considère indispensable à mes développements, donc je l'implémente à côté et je l'utilise.
D'autres la trouvent pratique et l'utilise de même.

Tu peux voir cela comme un "referendum d'initiative populaire visant à dévoyer la bonne direction à prendre pour le développement de SPIP".

Je vois ça comme le fait que ça répond à un besoin et c'est le principe même de la coopétition des idées. On ne décrète pas ce qui va marcher ou pas, ce qui va être utile aux utilisateurs ou non.

On esssaye, on propose, certaines idées tombent à l'eau (et croit moi, j'ai plus d'une proposition sur la zone qui sont tombées dans le néant, sans que j'en éprouve pour autant de la rancoeur, c'est le jeu), d'autres plaisent et sont adoptées.

Déclarer à ce moment là que ce n'est pas ce qu'il faut faire et que ceux qui utilisent ça font mal est assez contre-productif et suicidaire.
Il ne reste qu'à l'adopter ou proposer mieux, à mon humble avis.

Mais je ne me battrai pas sur ce point, j'ai pas envie d'être le méchant qui essaye d'imposer ses idées ou de faire le dictateur, et je laisse le soin à ceux qui savent quelle direction doit prendre le produit SPIP prendre les décisions qui s'imposent.

Cédric

10

Hello,

J’aimerais ajouté un avis un distancié sur cette feature de boucle itérative, et de boucle condition tand qu’on y est.

Je crois à l’usage que c’est effectivement très pratique. J’y vois cependant l’inconvenant que ca semble casser la logique des boucles spip originales, a savoir être une surccouche pour accéder à la base de donnée, c’est donc dérogatoire de fait.

Je crois qu’une sortie de crise élégante consisterait à :

  1. peaufiner la syntaxe : (POUR) → (ITERATION) comme on a hierarchie, par exemple.
  2. le mettre dans un plugin « Boucles d’interfaces », le temps que ca soit plus mature, ce plugin pourrait ensuite passer dans /extensions

Même topo pour toutes les différentes features de Bonux, je crois qu’a ce stade, Bonux tout intégré est un frein au progres.

Enfin, que des trucs pétent quand on évolue, on a déjà connu (genre les documents_articles qui deviennent document_liens on a du changer les squelettes), donc ce n’est pas forcement la peine de monter sur ses grands chevaux au taquet à chaque occasion, discutons plutôt en mode pro/serein, de préférence avant d’agir quand c touchy, et zou.

BoOz

Le 9 octobre 2009 12:21, cedric.morin@yterium.com <cedric.morin@yterium.com> a écrit :

Le 8 oct. 2009 à 21:42, Committo,Ergo:sum a écrit :

Ce n’est pas un secret que tu as cassé cette boucle à plusieurs
reprises, et qu’on te l’a signalé, à plusieurs reprises.

Mon point de vue est que si cette boucle est aussi fragile,
c’est quil y a un pb de conception soit dans le compilateur soit chez elle.
Et c’est de ça qu’il faudrait parler.

Bien volontiers.

Le fait est qu’une structure itérative dans les squelettes est grandement utile au portage de nombreux script php sous forme de squelette, ce qui accèlere le développement, la maintenance, et permet potentiellement à des contributeurs ne maitrisant pas php de contribuer au développement de l’interface privée, où d’autres interfaces.

Chaque fois que nous avons évoqué le problème ensemble tu es resté sceptique car tu n’en vois pas l’intérêt par rapport à un filtre php et un foreach dedans (c’est ce que j’ai compris)

La solution actuelle qui est dans Bonux n’a pas une syntaxe idéale car elle a été développée sans toucher au compilateur pour être la plus stable et durable possible (au contraire des anciennes boucles tableau de piif, qui réécrivaient plein de code généré par la boucle, et étaient dures à maintenir).

Plus le temps passe dans cette situation, plus la syntaxe actuelle, non idéale, va s’imposer de fait, et plus il sera compliqué d’en changer. On pourra encore dire à ce moment là que ce truc là est mal foutu/pensé et tout casser. Mais force est de constater que ce serait plus simple de prendre le sujet dès le début pour éviter d’en arriver là.

La boucle a cassé à plusieurs reprises sur des changements non mineurs :

  • la suppression du strlower sur les noms de table
  • l’ajout d’un pré-requis implicite sur les interface sql dont sql_select devait renvoyer une ressource exclusivement.

Sur le fond, il est certain qu’intégrer la structure itérative au core serait la solution la plus stable et perenne pour tout le monde.

On peut considérer que faire du dev sur la zone est « prendre le maquis ».

En l’occurence c’est purement pragmatique :
J’ai proposé la fonctionnalité dans le core.
Elle a été rejetée car pas jugée pas opportune.
Je la considère indispensable à mes développements, donc je l’implémente à côté et je l’utilise.
D’autres la trouvent pratique et l’utilise de même.

Tu peux voir cela comme un « referendum d’initiative populaire visant à dévoyer la bonne direction à prendre pour le développement de SPIP ».

Je vois ça comme le fait que ça répond à un besoin et c’est le principe même de la coopétition des idées. On ne décrète pas ce qui va marcher ou pas, ce qui va être utile aux utilisateurs ou non.

On esssaye, on propose, certaines idées tombent à l’eau (et croit moi, j’ai plus d’une proposition sur la zone qui sont tombées dans le néant, sans que j’en éprouve pour autant de la rancoeur, c’est le jeu), d’autres plaisent et sont adoptées.

Déclarer à ce moment là que ce n’est pas ce qu’il faut faire et que ceux qui utilisent ça font mal est assez contre-productif et suicidaire.
Il ne reste qu’à l’adopter ou proposer mieux, à mon humble avis.

Mais je ne me battrai pas sur ce point, j’ai pas envie d’être le méchant qui essaye d’imposer ses idées ou de faire le dictateur, et je laisse le soin à ceux qui savent quelle direction doit prendre le produit SPIP prendre les décisions qui s’imposent.

Cédric

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

11

Cher Cédric

Plutôt que de répondre directement à la question de la boucle dérogatoire que tu proposes,
voici quelques réflexions sur un problème plus général qui sous-tend celui-ci et quelques autres.

SPIP était au départ un CMS, avec comme beaucoup d'autres un système de "templates", comme on dit,
mais qui avait l'originalité d'être moins une extension de PHP que de HTML.
Avec le temps, et en particulier (quoique pas exclusivement) de par ton travail,
ce système est devenu un langage de programmation.
Comme beaucoup de CMS, SPIP n'est maîtrisable que si on apprend
- un langage de balisage (HTML)
- un langage de mise en page (CSS)
- un langage de programmation côté client (Javascript, plus une de ses bibliothèques, JQuery)
- un langage de programamtion côté serveur (PHP)
- un langage de requêtes sur bases de données (SQL)
mais en plus il faut apprendre un deuxième langage côté serveur, à la syntaxe farfelue et la sémantique indéfinie.

J'exprime ça dans un vocabulaire de chercheur, mais ce problème est perçu plus ou moins consciemment par tout le monde:
pour une entreprise, ce langage veut dire plusieurs jours de formation (sur le tas ou, pire, payantes) pendant lesquels
ses ingénieurs seront improductifs; pour une assoc', c'est plusieurs jours où l'action militante sera mise en veille.
Tu m'accorderas donc que cette évolution (je n'ai pas dit que j'étais contre hein) mérite qu'on se pose la question du pourquoi et du comment.

Le pourquoi n'est pas trivial, ni sur le plan théorique ni sur le plan pratique. Je pense d'ailleurs que c'est la raison profonde, au-delà des goûts et des couleurs, du clivage entre Arnaud et toi sur l'espace privé: Arnaud voit toujours SPIP comme un CMS intégrant un outil de développement, toi tu le vois comme un outil de développement fourni avec une application type. Rien que la persistance de votre incompréhension mutuelle me pousserait déjà à dire que sur le plan pratique de la bonne entente de l'équipe, il vaut mieux que le noyau continue à se présenter comme un CMS, et que tu développes ce qui tire SPIP vers autre chose seulement sur la Zone.

Sur un plan plus théorique, faire de SPIP un langage ne peut convaincre que s'il vient en remplacement de PHP, pas en plus pour la raisons susdite, et qu'il soit meilleur. Ce remplacement veut dire qu'il n'y aurait plus aucun nécessité d'écrire du PHP dans les squelettes, mais aussi qu'il n'y aurait plus besoin d'écrire des filtres et des balises perso en PHP. Par en dessous ça peut rester ou non du PHP, c'est secondaire pour l'utilisateur; evidemment il vaudrait mieux que ce soit un module Apache en C, mais c'est un boulot énorme. Mais je ne crois pas à la viabilité d'un langage aussi dépendant d'un autre, a fortiori quand celui-ci est lui-même mal fichu.

On en vient au "comment", et de nouveau il y a un aspect théorique et un aspect pratique. L'aspect pratique, c'est qu'en tant que chercheur en langage de programmation je me retrouverais dans une position très particulière dans l'équipe, qui ne serait pas très facile à vivre pour tout le monde parce que je pousserais vers certaines exigences qui sont considérées comme indispensables, à tort ou à raison, dans la communauté scientifique à laquelle j'appartiens. Quant au plan théorique, il faut savoir qu'on définit la sémantique d'un langage par un nombre d'instructions *minimal*, c'est-à-dire qu'aucune des instructions de ce noyau ne peut être définie par une composition des autres, ce qui garantit une rapidité d'apprentissage pour les utilisateurs, et des possibilités de développement par macro-génération pour les développeurs.

En l'occurrence, le noyau du langage de squelettes devrait se limiter aux boucles sur tables SQL (pour accéder aux infos en base), aux filtres (pour les traiter), et à un *unique* mécanisme d'inclusion. Les balises SPIP, en particulier, n'ont rien à faire dans le noyau, et elles y sont d'autant plus mal venues que leur interface de programmation n'est pas fondée sur une macro-génération, ce qui rend leur programmation compliquée.

Pour dire les choses autrement, l'allègement du noyau que tu as entamé depuis avant même la sortie de la 2.0 concerne l'aspect CMS de SPIP, pas son aspect langage qui s'est au contraire développé. Je ne dis pas que ce travail est inutile, bien au contraire, mais pour moi il est intervenu trop tôt: il faut d'abord définir le noyau sémantique pour savoir comment écrire au mieux les couches qu'on au-dessus.

Emmanuel

12

Le 12 oct. 2009 à 13:13, Committo,Ergo:sum a écrit :

Le pourquoi n'est pas trivial, ni sur le plan théorique ni sur le plan pratique. Je pense d'ailleurs que c'est la raison profonde, au-delà des goûts et des couleurs, du clivage entre Arnaud et toi sur l'espace privé: Arnaud voit toujours SPIP comme un CMS intégrant un outil de développement, toi tu le vois comme un outil de développement fourni avec une application type. Rien que la persistance de votre incompréhension mutuelle me pousserait déjà à dire que sur le plan pratique de la bonne entente de l'équipe, il vaut mieux que le noyau continue à se présenter comme un CMS, et que tu développes ce qui tire SPIP vers autre chose seulement sur la Zone.

La question ne me semble pas là. Pas tellement d'accord, non plus, pour être celui qui a une idée passéiste et anti-évolutions de SPIP :-))

=> À une époque extrêmement ancienne (je ne me souviens pas bien, mais ça doit être dans les derniers mois de la présence d'Antoine - le seul qui se souvient de ça, ça doit être Fil), j'avais commencé à bosser sur un truc qui s'appelait «SADE» (Système automatisé de développement et l'édition).

Quand j'ai vu arriver le nouveau moteur (1.8) et, plus récemment, Extra 2, ça m'a plus rappelé des souvenirs que surpris. Plus récemment, j'ai retrouvé un peu de ces idées, mais fonctionnelles, dans le petit système de base de données Bento.

Le principe était de conserver la logique de SPIP (système de publication) mais entièrement ouvert à de nouveaux objets.
- D'abord, pouvoir modifier/créer des objets (articles, rubriques, etc.), mais avec un interface graphique. Là un champ textarea, là une date, là une ligne, etc.
- Surtout, définir également graphiquement les relations entre les objets. Pas simplement des liaisons, mais des dépendances indiquant un sens (les articles dépendent des rubriques, mais les rubriques ne dépendent pas des articles, les auteurs dépendent des articles, etc.).
- Ce faisant, il me semblait possible, via ce système graphique, d'avoir à la fois la souplesse de créer et manipuler les objets, mais aussi de réaliser l'interface graphique qui permettrait de créer automatiquement une interface _intégrée_ comme dans SPIP (et pas juste des formulaires: retrouver pourquoi on affiche les articles _dans les rubriques_, où on présente les auteurs dans les articles, comment une rubrique dépend d'une seule rubrique, etc.).

Ça n'a pas été très loin, parce que:
- techniquement, on n'avait pas le moteur,
- au niveau conceptuel, il n'y avait et il n'y a toujours pas grand chose de similaire (à part, dans une certaine mesure, Bento),
- la gestion des droits était problématique (sauf à faire comme aujourd'hui: des profils-type),
- surtout (et c'est important): ça n'a intéressé rigoureusement personne,

=> On retrouve en partie cette idée, à la suite de nos discussions, dans le mémoire de Diala:
http://diala.rezo.net/article.php3?id_article=25

-----------

De fait, si SPIP devient un outil de développement dont l'outil «SPIP» de publication n'est qu'une application type, je serai très content, parce que c'est la piste que j'envisageais pour «dépasser» les limitations de SPIP à une époque déjà bien ancienne.

Les points qui, en revanche, me semblent sensibles:

- des frameworks, y'en a d'autres; c'est pas la peine de casser le cœur SPIP pour faire Ruby On Rails; mais je n'ai pas vraiment l'impression que ce soit non plus ce à quoi pense Cédric.

- la caractéristique centrale et fondatrice de SPIP, pour moi, c'est l'aspect intégré de son interface, au contraire de tous les autres systèmes; dans les discussions sur le mémoire de Diala, ça ressort très nettement: cet aspect pose de grosses lourdeurs, mais a aussi des avantages énormes:
http://diala.rezo.net/article.php3?id_article=10
À ce titre, l'idée d'une interface «pas à pas» évoquée récemment n'a à mon avis aucun sens: l'interface de SPIP est déjà _intégrée_, justement, et doit être conçue pour induire la création d'un site cohérent. L'interface accompagne donc déjà, dès l'origine, le rédacteur et le débutant, en ce qu'elle insiste lourdement sur la cohérence du processus éditorial. Après, que cet aspect soit imparfait, évidemment; mais que ce soit ça le principe fondateur de SPIP, je n'en démords pas.

- c'est cette logique d'ouverture tout en continuant à travailler à une interface intégrée qui était exactement ce qui guidait mes réflexions sur SADE. Pas un catalogue d'objets dans une interface modulaire, mais des méthodes systématiques permettant de reproduire automatiquement l'aspect intégré de l'interface sur n'importe quel objet.

Quand je vois les développements vers plus de souplesse, j'ai vraiment le sentiment qu'ils ne vont pas dans ce sens. Que ce soit Extra, les définitions des liaisons entre tables, etc., il manque un étage pour pouvoir faire autre chose qu'une bête présentation modulaire. Les informations pour reconstituer une véritable interface intégrée ne sont pas présents. Je vois aussi les différents plugins, et ils sont la plupart du temps conçus avec des interfaces modulaires et non intégrées. SPIP-Listes, par exemple, avait une interface très compliquée à cause de cela, et les nouvelles versions me semblent avoir fait de gros progrès vers la logique intégrée de SPIP (on retrouve beaucoup plus logiquement ses petits).

À mon avis, l'une des difficultés se situe là. Pas sur la transformation de SPIP en système ouvert, mais sur le fait que cette ouverture ne se fait pas dans la logique d'une interface intégrée. Or on aurait là un véritable force et une véritable originalité. Comparer Bento avec un logiciel de base de données plus classique, c'est spectaculaire (même si, en même temps, Bento ne gère pas terriblement les relations - il ne gère qu'un seul type de relation assez pauvre).

Voir par exemple /base/serial.php: c'est épatant, mais c'est une pure logique de base de données. L'étape supplémentaire dont je parle, ce serait que les objets et les champs soient définis non en logique SQL, mais en logique éditoriale. Et les «join» seraient également avec une logique éditoriale (avec par exemple un sens dans les relations, savoir si les liens sont uniques, obligatoires, etc.). Avec une telle description éditoriale, on aurait à mon avis la possibilité de créer:
- la structure de la base de données (quitte à utiliser plusieurs champs pour une même info dans certains cas très spécifiques),
- les relations automatiquement (dire que les auteurs dépendent des articles, que plusieurs auteurs peuvent être reliés à un article; que les articles dépendent des rubriques mais qu'ils peuvent être dans une seule rubrique - un truc facile à changer, alors, si on décide qu'un article peut dépendre de plusieurs rubriques).
- les pages d'affichage des objets
- les formulaires d'édition des objets
- les filtres appliqués automatiquement à chaque champ (actuellement définis ailleurs),
- les systèmes d'URL arborescents (l'article est dans une rubrique qui est dans une rubrique qui est à la racine du site, d'où l'URL).

Là, on est coincés: soit c'est fait main (c'est fait main), soit quand on fait une page «automatique», c'est aussi marrant et structuré qu'un formulaire de PHPMyAdmin.

Les évolutions d'interface, souvent bienvenues, ne devraient pas à mon avis perdre de vue l'aspect intégré de l'ergonomie et, au moins, s'interroger sur l'opposition entre ergonomie intégrée/modulaire pour savoir pourquoi on passe de l'une à l'autre.

Arnaud

13

Le 12 oct. 09 à 17:14, Martin Arnaud a écrit :

Arnaud voit toujours SPIP comme un CMS intégrant un outil de développement, toi tu le vois comme un outil de développement fourni avec une application type. Rien que la persistance de votre incompréhension mutuelle me pousserait déjà à dire que sur le plan pratique de la bonne entente de l'équipe, il vaut mieux que le noyau continue à se présenter comme un CMS, et que tu développes ce qui tire SPIP vers autre chose seulement sur la Zone.

La question ne me semble pas là. Pas tellement d'accord, non plus, pour être celui qui a une idée passéiste et anti-évolutions de SPIP :-))...

Je me suis sans doute mal exprimé, mais tout ton mail confirme ce que je voulais y dire.
Je ne t'accuse pas de passéisme, je dis seulement que tu veux quelque chose d'intégré,
alors que Cédric et moi sommes plus intéressé par l'aspect "boit à outils",
outils qu'on est pas très gênés de laisser en vrac, c'est-à-dire pas du tout intégré.

Ensuite, ton désir de "description de relations qui ne soit pas calqué sur SQL mais sur les logiques éditoriales",
ça s'appelle inventer un nouveau langage.

Au final, je pense donc que nous sommes d'accord sur là où est la question.

Emmanuel

14

Salut,
je me permet d'intervenir, car je pense que le probleme est profond alors que vous parlez de points de détails en surface...

Committo,Ergo:sum a écrit :

SPIP était au départ un CMS, avec comme beaucoup d'autres un système de "templates", comme on dit,
mais qui avait l'originalité d'être moins une extension de PHP que de HTML.
Avec le temps, et en particulier (quoique pas exclusivement) de par ton travail,
ce système est devenu un langage de programmation.
Comme beaucoup de CMS, SPIP n'est maîtrisable que si on apprend
- un langage de balisage (HTML)
- un langage de mise en page (CSS)
- un langage de programmation côté client (Javascript, plus une de ses bibliothèques, JQuery)
- un langage de programamtion côté serveur (PHP)
- un langage de requêtes sur bases de données (SQL)
mais en plus il faut apprendre un deuxième langage côté serveur, à la syntaxe farfelue et la sémantique indéfinie.

Si je peux me permettre, justement pas !
SPIP permet à des non informaticiens, n'ayant aucune notion de programmation, d'adapter à leur besoin un "produit" (spip seul ou avec squelette "clé en main").
Il n'y a qu'à suivre la liste user pour voir que tres souvent, la demande est juste "comment n'afficher que ceci, afficher cela ou ne pas afficher ce bidule".
pour 90% des utilisateurs, la connaissance necessaire se resume à comprendre comment modifier les 3 boucles qui les interessent.
Le deuxieme niveau consiste à monter en compétence sur CSS et HTML (encore que tout est fait pour que CSS suffise)
Optionnellement, ils peuvent vouloir ajouter un peu de jquery (encore qu'ici aussi, certains plugins peuvent suffire)
Quand on commence à devoir faire du PHP ou du SQL, c'est qu'on est déjà en train de faire autre chose ou un peu plus qu'un site internet.

J'exprime ça dans un vocabulaire de chercheur, mais ce problème est perçu plus ou moins consciemment par tout le monde:
pour une entreprise, ce langage veut dire plusieurs jours de formation (sur le tas ou, pire, payantes) pendant lesquels
ses ingénieurs seront improductifs; pour une assoc', c'est plusieurs jours où l'action militante sera mise en veille.
Tu m'accorderas donc que cette évolution (je n'ai pas dit que j'étais contre hein) mérite qu'on se pose la question du pourquoi et du comment.

Je suis d'accord avec ton constat "en entreprise" et plus particulièrement "en SSII".
Oui, pas mal d'ingénieurs diplomés font la gueule quand il faut faire du SPIP.
Pire : ils n'y comprennent rien et ralent que c'est compliqué.
Mais si tu creuses un peu, tu te rends vite compte qu'en fait, leur probleme, c'est qu'ils sont formatés pour la programmation objet à tel point qu'ils ne savent meme plus pourquoi ils en font, mais qu'ils ne savent pas faire autre chose !
J'ai en memoire une réunion assez amusante ou un chef de projet essayait d'expliquer tout le mal qu'il pensait de SPIP, je pense qu'il m'en veut encore beaucoup... car il n'a pas réussit à trouver un argument tenant la route et que j'ai démoli point par point sa belle conception objet : c'etait beau, conceptuellement tres propre, mais c'etait clairement plus couteux en programmation et ca n'avait aucun interet (ni perf, ni maintenance, ni fonctionnel).

Je suis venu à SPIP car justement, c'est un projet qui se pose les bonnes questions et apporte des reponses opérationnelles.

Le pourquoi n'est pas trivial, ni sur le plan théorique ni sur le plan pratique. Je pense d'ailleurs que c'est la raison profonde, au-delà des goûts et des couleurs, du clivage entre Arnaud et toi sur l'espace privé: Arnaud voit toujours SPIP comme un CMS intégrant un outil de développement, toi tu le vois comme un outil de développement fourni avec une application type. Rien que la persistance de votre incompréhension mutuelle me pousserait déjà à dire que sur le plan pratique de la bonne entente de l'équipe, il vaut mieux que le noyau continue à se présenter comme un CMS, et que tu développes ce qui tire SPIP vers autre chose seulement sur la Zone.

Je crois plutot que chacun voit midi à sa porte...
Et le plus important pour chacun, amha, c'est la compatibilité ascendante.
Arnaud est plus sensible aux pratiques en place (process de rédaction), Cedric plus au développement (formulaires, plugins...) mais au final, c'est juste qu'ils ne veulent pas avoir perdu leur temps et etre obligés de recommencer qqchose qui a été fait (que ca soit du developpement ou de la formation).

Sur un plan plus théorique, faire de SPIP un langage ne peut convaincre que s'il vient en remplacement de PHP, pas en plus pour la raisons susdite, et qu'il soit meilleur. Ce remplacement veut dire qu'il n'y aurait plus aucun nécessité d'écrire du PHP dans les squelettes, mais aussi qu'il n'y aurait plus besoin d'écrire des filtres et des balises perso en PHP. Par en dessous ça peut rester ou non du PHP, c'est secondaire pour l'utilisateur; evidemment il vaudrait mieux que ce soit un module Apache en C, mais c'est un boulot énorme. Mais je ne crois pas à la viabilité d'un langage aussi dépendant d'un autre, a fortiori quand celui-ci est lui-même mal fichu.

alors la, super pas d'accord !!!
justement, il y a une "courbe d'apprentissage" dans SPIP qui permet aux bidouilleurs de trouver leur bonheur, quel que soit leur niveau.
Pas besoin d'un BAC+5 pour faire une petite fonction PHP qui fera la petite bidouille souhaitée sur un champ.
Grace à SPIP, non seulement le bidouilleur arrive à faire ce qu'il veut très vite, mais en plus, il le fait bien (utilisation du cache).

C'est la je pense ou tu es le plus en décalage :

D'après toi, qui sont les utilisateurs de SPIP ?
Qu'attendent-ils d'une nouvelle version de l'outil qu'ils ont choisi pour leur site et sur lequel ils ont passé des heures ?
Qu'il soit un langage de programmation indépendant ?
Qu'il soit compatible avec Oracle ?

je ne pense pas...

Ils veulent pouvoir faire des sites et autres extranet simplement, rapidement, avec du code solide et maintenable.
Et quand je parle de maintenable, je parle de leur code à eux (squelettes, filtres, plugins pour les plus geek...), pas de celui de SPIP.

On en vient au "comment", et de nouveau il y a un aspect théorique et un aspect pratique. L'aspect pratique, c'est qu'en tant que chercheur en langage de programmation je me retrouverais dans une position très particulière dans l'équipe, qui ne serait pas très facile à vivre pour tout le monde parce que je pousserais vers certaines exigences qui sont considérées comme indispensables, à tort ou à raison, dans la communauté scientifique à laquelle j'appartiens. Quant au plan théorique, il faut savoir qu'on définit la sémantique d'un langage par un nombre d'instructions *minimal*, c'est-à-dire qu'aucune des instructions de ce noyau ne peut être définie par une composition des autres, ce qui garantit une rapidité d'apprentissage pour les utilisateurs, et des possibilités de développement par macro-génération pour les développeurs.

Tu le sais, je suis à priori, et pour mes besoins, tout à fait d'accord avec cette approche.
Mais malheureusement, c'est loin d'etre compatible avec le besoin de la majorité des utilisateurs !

En l'occurrence, le noyau du langage de squelettes devrait se limiter aux boucles sur tables SQL (pour accéder aux infos en base), aux filtres (pour les traiter), et à un *unique* mécanisme d'inclusion. Les balises SPIP, en particulier, n'ont rien à faire dans le noyau, et elles y sont d'autant plus mal venues que leur interface de programmation n'est pas fondée sur une macro-génération, ce qui rend leur programmation compliquée.

Si tu arrives à faire ca sans casser la compatibilité ascendante, je pense que tout le monde sautera de joie... malheureusement, ca n'est pas possible, en tous cas, pas proprement.
Ca pourrait etre l'objecctif d'un SPIP 3.0...

Pour dire les choses autrement, l'allègement du noyau que tu as entamé depuis avant même la sortie de la 2.0 concerne l'aspect CMS de SPIP, pas son aspect langage qui s'est au contraire développé.

heu, depuis la 1.9.2, il y a quand meme du chemin de fait au niveau de la mise en place d'une API (ou tout du moins au niveau du modele de programmation)

Je ne dis pas que ce travail est inutile, bien au contraire, mais pour moi il est intervenu trop tôt: il faut d'abord définir le noyau sémantique pour savoir comment écrire au mieux les couches qu'on au-dessus.

La aussi, je pense qu'il y a une difference de points de vue fondamentale entre les differentes visions de SPIP.
Quand je présente SPIP, je dis :
1- SPIP est avant tout un présentateur de contenu : son langage de boucles/balises/filtres permet d'afficher n'importe quel contenu situé en base de données avec une grande souplesse et en exploitant un systeme de cache intégré
2- SPIP est livré nativement avec un backoffice gérant un ensemble d'objets => ce que tu appelles l'aspect CMS
3- SPIP dispose d'une large communauté et de nombreux plugins => pour des besoins classiques, on trouve presque toujours son bonheur
4- SPIP permet de gérer n'importe quel contenu en base moyennant un petit developpement : les balises dynamiques (1.9.2) ou formulaires CVT (2.0)
5- SPIP est surchargeable et bien foutu (autorisations, cron, mots clés, syndication...)
=> SPIP est un framework : il simplifie et structure la programmation.

Le progrès principal de SPIP 2.0, c'est de ne pas devoir faire d'un coté une balise dynamique et des squelettes, et de l'autre la programmation d'un backoffice.
C'etait le plus gros defaut de la 1.9.

A aucun moment je ne dis que SPIP est un langage, je dis que c'est un framework PHP.
La compatibilité avec d'autres base ? on ne me l'a jamais demandé, quand SPIP arrive sur un projet, c'est que PHP/MySQL est la plateforme retenue.

Pour moi, aujourd'hui, la limite fonctionnelle la plus bloquante dans SPIP, c'est de ne pas pouvoir faire des boucles sur autre chose que des tables.
C'est le seul truc sur lequel je continue à dire "ah non, désolé, c'est pas possible" et c'est une chose qui m'est demandée presque systematiquement pour les résultats de recherche.

Alors oui, les bonnes questions aujourd'hui, c'est :
- Est-ce qu'une balise est un champ SQL ou est-ce juste le comportement par defaut en l'absence de balise programmée (statique ou dynamique) ?
- Est-ce qu'une boucle est un générateur de SQL/PHP ou un itérateur ?
- Est ce que SPIP est un langage ou un framework PHP ?

Une chose est sure : les utilisateurs se positionnent d'un point de vue fonctionnel, la "qualité" du core, tant que ca n'impacte pas les perfs ni la sécurité, sans dire qu'ils s'en tamponnent, je dirais que c'est tres tres secondaire et qu'ils ne sont sans doute pas pour lui sacrifier la moindre fonctionnalité acquise...

Le constat aujourd'hui, c'est des centaines de sites en 1.9.2 qui ne migreront sans doute jamais en 2.0, de quoi se faire du souci pour l'avenir de ce qui a été programmé pour la 2.0, des plugins faisant l'impasse sur la 2.0, ... bref, de quoi dégouter bien plus d'utilisateurs que n'en attirera la compatibilité Oracle ou la beauté de la conception du core.

Voila, tout ca pour dire que, oui, sur le principe, ce que tu decris est tres bien, mais tu ne peux pas le faire si les utilisateurs sont perdants...

Mes 2 sous.
Stephane

15

Cher Emmanuel,

Le 12 oct. 2009 à 13:13, Committo,Ergo:sum a écrit :

Cher Cédric

Plutôt que de répondre directement à la question de la boucle dérogatoire que tu proposes,
voici quelques réflexions sur un problème plus général qui sous-tend celui-ci et quelques autres.

SPIP était au départ un CMS, avec comme beaucoup d'autres un système de "templates", comme on dit,
mais qui avait l'originalité d'être moins une extension de PHP que de HTML.
Avec le temps, et en particulier (quoique pas exclusivement) de par ton travail,
ce système est devenu un langage de programmation.
Comme beaucoup de CMS, SPIP n'est maîtrisable que si on apprend
- un langage de balisage (HTML)
- un langage de mise en page (CSS)
- un langage de programmation côté client (Javascript, plus une de ses bibliothèques, JQuery)

ça n'est pas propre aux CMS, mais l'essence même du web, en ce qui concerne ces 3 technologies

- un langage de programamtion côté serveur (PHP)
- un langage de requêtes sur bases de données (SQL)
mais en plus il faut apprendre un deuxième langage côté serveur, à la syntaxe farfelue et la sémantique indéfinie.

Mais pour commencer à faire un site web, le langage de SPIP permet justement d'éviter d'apprendre PHP et SQL au profit d'une abstraction plus abordable pour les débutants.
Pour la maîtrise, certes, mais dans ce cas l'utilisation des squelettes SPIP n'a plus la même finalité : il ne s'agit plus d'éviter d'aborder 2 langages complexes, mais d'aller plus vite sur tout ce qui est assez simple, comme pour tout autre système de templating.

J'exprime ça dans un vocabulaire de chercheur, mais ce problème est perçu plus ou moins consciemment par tout le monde:
pour une entreprise, ce langage veut dire plusieurs jours de formation (sur le tas ou, pire, payantes) pendant lesquels
ses ingénieurs seront improductifs; pour une assoc', c'est plusieurs jours où l'action militante sera mise en veille.
Tu m'accorderas donc que cette évolution (je n'ai pas dit que j'étais contre hein) mérite qu'on se pose la question du pourquoi et du comment.

Le pourquoi n'est pas trivial, ni sur le plan théorique ni sur le plan pratique. Je pense d'ailleurs que c'est la raison profonde, au-delà des goûts et des couleurs, du clivage entre Arnaud et toi sur l'espace privé: Arnaud voit toujours SPIP comme un CMS intégrant un outil de développement, toi tu le vois comme un outil de développement fourni avec une application type.

Que nenni.
Il y a le côté 'plateforme de développement' que j'essaye de faire avancer en fonction des besoins des développeurs, dont je fais partie.
Et il y a le côté 'Outil de publication' que j'essaye de faire progresser dans son usabilité. Et sur ce point ce n'est pas "mes besoins" que j'exprime, mais je fait juste remonter les écueils sur lesquels je vois les débutants tomber à chaque fois qu'ils sont devant l'interface de ecrire/. Que ce soit aux apéros où j'essaye de continuer à aller régulièrement (ça aide à se souvenir que de simples manipulations triviales ne le sont pas tant que ça...), ou lorsque je fais des formations à des utilisateurs novices.
Je pleure sincèrement de voir ces utilisateurs débutants échouer sur les mêmes défauts depuis des années.

Pour moi les deux aspects de SPIP ne sont pas contradictoires, bien au contraire. Améliorer la plateforme de développement, c'est permettre de développer plus facilement et rapidement des interfaces pour rendre SPIP plus simple d'utilisation comme 'outil de publication'.
C'est le langage au service du développeur au service de l'utilisateur.

Rien que la persistance de votre incompréhension mutuelle me pousserait déjà à dire que sur le plan pratique de la bonne entente de l'équipe, il vaut mieux que le noyau continue à se présenter comme un CMS, et que tu développes ce qui tire SPIP vers autre chose seulement sur la Zone.

La limite de cela est double :
- on ne dispose pas de ces outils pour développer SPIP lui même, et paradoxalement il est plus facile de développer l'interface d'un plugin en se basant sur ces fonctionnalités étendues du langage que dans SPIP
- le développement d'une structure itérative en dehors du compilateur a pour conséquence une syntaxe pas idéale qui est un compromis entre ce qu'on voudrait et ce qu'on peut faire sans avoir des tonnes de codes forkées à maintenir à la moindre évolution du core.

Sur un plan plus théorique, faire de SPIP un langage ne peut convaincre que s'il vient en remplacement de PHP, pas en plus pour la raisons susdite, et qu'il soit meilleur. Ce remplacement veut dire qu'il n'y aurait plus aucun nécessité d'écrire du PHP dans les squelettes, mais aussi qu'il n'y aurait plus besoin d'écrire des filtres et des balises perso en PHP. Par en dessous ça peut rester ou non du PHP, c'est secondaire pour l'utilisateur; evidemment il vaudrait mieux que ce soit un module Apache en C, mais c'est un boulot énorme. Mais je ne crois pas à la viabilité d'un langage aussi dépendant d'un autre, a fortiori quand celui-ci est lui-même mal fichu.

Je ne pense pas SPIP comme un langage a part entière, mais comme une plateforme de développement/framework/cadriciel.
Il ne fait pas disparaître la couche du dessous, mais il accélère le développement. C'est en ça qu'il a un intérêt et qu'il rentabilise son coût d'apprentissage.

On en vient au "comment", et de nouveau il y a un aspect théorique et un aspect pratique. L'aspect pratique, c'est qu'en tant que chercheur en langage de programmation je me retrouverais dans une position très particulière dans l'équipe, qui ne serait pas très facile à vivre pour tout le monde parce que je pousserais vers certaines exigences qui sont considérées comme indispensables, à tort ou à raison, dans la communauté scientifique à laquelle j'appartiens. Quant au plan théorique, il faut savoir qu'on définit la sémantique d'un langage par un nombre d'instructions *minimal*, c'est-à-dire qu'aucune des instructions de ce noyau ne peut être définie par une composition des autres, ce qui garantit une rapidité d'apprentissage pour les utilisateurs, et des possibilités de développement par macro-génération pour les développeurs.

C'est un débat assez récurent que l'on a retrouvé dans l'opposition entre les architectures RISC/CISC des microprocesseurs, microkernel/noyau monolithique dans les Unix.
Je n'ai pas le background historique suffisant, mais dans les deux exemples précédents, c'est l'architecture riche qui s'est imposée par rapport à l'architecture reposant sur une version minimale/réduite.
As-tu un exemple d'un langage minimal qui se soit imposé dans l'usage ? J'ai l'impression que tous les langages répandus ont intégrés, pragmatiquement, des structures riches qui pouvaient pourtant se déduire d'un noyau minimal.

Car il me semble que le langage n'est pas fait pour être beau du point de vue du chercheur, mais pratique et efficace à utiliser du point de vue de son utilisateur (donc dans notre cas, ceux qui développent des sites ou applications web basées sur SPIP).

Et c'est exactement le même débat qui sous tend l'interface de SPIP.
On peut défendre toute la beauté théorique ou supposée d'une construction, elle n'a pour moi de valeur que si elle rend service à ses utilisateurs, dans les faits (les vrais gens dans la vraie vie qui essayent de faire un truc avec SPIP avec leurs connaissances, pas nous, ici, qui connaissons par coeur les chausses trappes et les circuits pour les éviter).

En l'occurrence, le noyau du langage de squelettes devrait se limiter aux boucles sur tables SQL (pour accéder aux infos en base), aux filtres (pour les traiter), et à un *unique* mécanisme d'inclusion. Les balises SPIP, en particulier, n'ont rien à faire dans le noyau, et elles y sont d'autant plus mal venues que leur interface de programmation n'est pas fondée sur une macro-génération, ce qui rend leur programmation compliquée.

En théorie.
Dans la pratique, retire les, et le système de template de SPIP perd 80% de son intérêt.

Pour dire les choses autrement, l'allègement du noyau que tu as entamé depuis avant même la sortie de la 2.0 concerne l'aspect CMS de SPIP, pas son aspect langage qui s'est au contraire développé. Je ne dis pas que ce travail est inutile, bien au contraire, mais pour moi il est intervenu trop tôt: il faut d'abord définir le noyau sémantique pour savoir comment écrire au mieux les couches qu'on au-dessus.

Mais à attendre, on risque de perdre les derniers courageux qui s'accrochent à la barque.
Et faire un SPIP pour les 10 seuls abonnés de cette liste qui n'arrivent pour la plupart du temps qu'à discuter rugueusement n'est pas un projet qui me fait très envie.

Cédric

16

Le 12 oct. 09 à 19:31, cedric.morin@yterium.com a écrit :

Je ne pense pas SPIP comme un langage a part entière, mais comme une plateforme de développement/framework/cadriciel.

Mais justement il en est un, et pour moi le pb c'est que tu nies cette réalité.

C'est un débat assez récurent que l'on a retrouvé dans l'opposition entre les architectures RISC/CISC des microprocesseurs, microkernel/noyau monolithique dans les Unix.
Je n'ai pas le background historique suffisant, mais dans les deux exemples précédents, c'est l'architecture riche qui s'est imposée par rapport à l'architecture reposant sur une version minimale/réduite.

QUOI ??? Mais c'est le contraire qui c'et passé ! Même Intel a été obligé de passer au CISC, en simulant son architecture RISC pour assurer la compatilité, d'où ses perfs moins bonnes à fréquences égales.
En ce qui concerne Unix, le débat n'est pas clos et Linux pourrait être conduit à la même évolution qu'Intel:
la minimalité est industriellement difficile mais ses atouts théoriques sont certains, elle a toute raison de gagner sur le long terme.

Car il me semble que le langage n'est pas fait pour être beau du point de vue du chercheur,

J'en ai assez d'entendre ça. Si c'était ça qui me conduisait j'aurais tout pété depuis le début.
Le vrai pb c'est qu'un programme formé d'une poignée de fichiers et un autre formé de millers,
ça ne se développe pas du tout de la même manière: dans le premier cas, il n'y a pas assez d'exemples pour constituer des règles dont la violation serait problématique, dans l'autre cas si.

En l'occurrence, le noyau du langage de squelettes devrait se limiter aux boucles sur tables SQL (pour accéder aux infos en base), aux filtres (pour les traiter), et à un *unique* mécanisme d'inclusion. Les balises SPIP, en particulier, n'ont rien à faire dans le noyau, et elles y sont d'autant plus mal venues que leur interface de programmation n'est pas fondée sur une macro-génération, ce qui rend leur programmation compliquée.

En théorie.
Dans la pratique, retire les, et le système de template de SPIP perd 80% de son intérêt.

Mais bon sang j'ai cité plein de fois l'exemple du couple HTML/CSS en disant que l'un sans l'autre ça ne vaut rien,
mais que pourtant c'est la bonne architecture; j'en ai marre qu'on n'oublie la moitié de ce je dis.
Tu devrais être content de m'entendre dire que SPIP ne serait plus utilisable sans plugins,
alors que jusqu'à présent je ne m'en sers pas.

Emmanuel

17

Le 12 oct. 09 à 19:25, Stephane a écrit :

mais en plus il faut apprendre un deuxième langage côté serveur, à la syntaxe farfelue et la sémantique indéfinie.

Si je peux me permettre, justement pas !
SPIP permet à des non informaticiens, n'ayant aucune notion de programmation, d'adapter à leur besoin un "produit" (spip seul ou avec squelette "clé en main").

Oui Stéphane, c'est pour ça que SPIP m'a toujours intéressé, mais là on parle des développements de niveau supérieur.

Je suis d'accord avec ton constat "en entreprise" et plus particulièrement "en SSII".

et voilà.

leur probleme, c'est qu'ils sont formatés pour la programmation objet à tel point qu'ils ne savent meme plus pourquoi ils en font, mais qu'ils ne savent pas faire autre chose !

tout à fait.

Je suis venu à SPIP car justement, c'est un projet qui se pose les bonnes questions et apporte des reponses opérationnelles.

moi aussi.

Mais je ne crois pas à la viabilité d'un langage aussi dépendant d'un autre, a fortiori quand celui-ci est lui-même mal fichu.

alors la, super pas d'accord !!!
justement, il y a une "courbe d'apprentissage" dans SPIP qui permet aux bidouilleurs de trouver leur bonheur, quel que soit leur niveau.

De nouveau ce n'est vrai que dans les premiers niveaux. Il y a une marche énorme entre écrire un squelette et écrire un filtre PHP qui sera pris en compte par le compilateur, et une marche encore plus grande quand on écrit une balise, a fortiori dynamique (même si CVT l'a heureusement un peu réduite).

Ils veulent pouvoir faire des sites et autres extranet simplement, rapidement, avec du code solide et maintenable.
Et quand je parle de maintenable, je parle de leur code à eux (squelettes, filtres, plugins pour les plus geek...), pas de celui de SPIP.

Mais je suis bien d'accord là-dessus. Seulement pour moi du code solide et maintenable, c'est un code écrit dans un langage pour lesquels il existe des outils d'aide à la mise au point. Et SPIP n'en a pas.

On définit la sémantique d'un langage par un nombre d'instructions *minimal*, c'est-à-dire qu'aucune des instructions de ce noyau ne peut être définie par une composition des autres, ce qui garantit une rapidité d'apprentissage pour les utilisateurs, et des possibilités de développement par macro-génération pour les développeurs.

Tu le sais, je suis à priori, et pour mes besoins, tout à fait d'accord avec cette approche.
Mais malheureusement, c'est loin d'etre compatible avec le besoin de la majorité des utilisateurs !

Mais en quoi cela ne le serait-il pas ?

Si tu arrives à faire ca sans casser la compatibilité ascendante, je pense que tout le monde sautera de joie... malheureusement, ca n'est pas possible, en tous cas, pas proprement.
Ca pourrait etre l'objecctif d'un SPIP 3.0...

Mais c'est bien de ça dont je parle depuis ma présentation d'Avignon.

Pour dire les choses autrement, l'allègement du noyau que tu as entamé depuis avant même la sortie de la 2.0 concerne l'aspect CMS de SPIP, pas son aspect langage qui s'est au contraire développé.

heu, depuis la 1.9.2, il y a quand meme du chemin de fait au niveau de la mise en place d'une API (ou tout du moins au niveau du modele de programmation)

Bah oui c'est ce que je dis: le langage s'est développé, mais au coup par coup, sans conception générale.

Je ne dis pas que ce travail est inutile, bien au contraire, mais pour moi il est intervenu trop tôt: il faut d'abord définir le noyau sémantique pour savoir comment écrire au mieux les couches qu'on au-dessus.

A aucun moment je ne dis que SPIP est un langage, je dis que c'est un framework PHP.

moi aussi parce qu'il est indéfendable en tant que langage. Mais quand les utilisateurs découvrent que c'en est AUSSI un, ils font la tronche.

La compatibilité avec d'autres base ? on ne me l'a jamais demandé,

Il faut sans doute que je dissipe un malentendu. Quand j'ai découvert SPIP je ne connaissais pratiquement rien de SQL. Par la suite, j'ai eu besoin de l'interfacer avec une base PG et j'ai appris les pbs d'incompatibilités entre eux, que j'ai résolus de manière assez peu satisfaisante. Mes collègues chercheurs en BD considèrent qu'Oracle est le système le plus en avance, partant je me suis dit qu'essayer d'y porter SPIP permettrait de me faire une idée complète des pbs de portabilité, et de ne pas passer à côté de fonctionnalités qui se seront banalisées dans quelques années (je pense en particulier à la réplication). Je faisais ça à très petite vitesse, et puis récemment Yohann m'a écrit perso en me disant qu'il avait un copain spécialiste d'Oracle que le portage intéressait. Donc, je donne un coup d'accélérateur, mais je n'ai jamais dit ou penser que j'allais rameuter les foules avec ça.

Le constat aujourd'hui, c'est des centaines de sites en 1.9.2 qui ne migreront sans doute jamais en 2.0,

mais ce constat il porte sur quoi ? Y a-t-il tellement moins de difficultés à passer de la 1.9.1 à la 1.9.2 que de passer de la 1.9.2 à la 2.0 ?
Pour moi, le pb est plus dans nos méthodes de travail, dans l'absence de doc aussi, que dans certains choix fait à un moment ou un à autre.

Emmanuel

18

Salut tout le monde

Je vais essayer d'apporter ma pierre à l'édifice. Je constate de ces
échanges qu'on a tous une vision parcellaire de notre projet. En effet
on voit tous une facette différente. Par exemple intégré/modulaire ,
langage/framework , ...

Pour autant toutes ces facettes ne sont pas opposables et c'est là
toute la force de cette oeuvre collaborative
(http://www.spip.net/ecrire/?exec=articles&id_article=2936)

Pour le cas d'esj, on voit que l'api SQL n'est pas encore aboutie. Que
ce soit pour le corps ou bien les plugins, ils nous faudra bien
stabiliser le tout.
Si j'ai bien suivi, porter Oracle ce n'est pas parce que c'est "Pro"
c'est aussi/surtout l'usine à gaz avec les cas les plus tordus. Si
cela marche avec lui, on limite les risques avec les autres portages.

Pour le cas Cedric/Arno/Romy, on voit que les approches sont intégrée
/ modulaire. On rajoute aussi les divergences esthétique et/ou
ergonomique.
Si je ne m'abuse on :
-* a un chantier de bandeau avec la liste, un plugin et contrib comme
terrain de jeu,
-* avait lancé un ensemble d'articles sur la structuration des pages
de l'espace privé.

Le fait d'avoir une charte de création de page d'espace privée va dans
le sens du tout intégré, du moins du tout cohérent.
Le bandeau me semble plus problématique même si pour ma part je ne
comprends pas trop cette différence intégré vs modulaire.
Je crois qu'en continuant à formaliser petit à petit ces travaux entre
autre sur spip.net, on pourrait trouver un terrain de jeu sympa.

Depuis que je suis par là, j'ai 'impression que notre
incompréhension/frustration vient de nos différentes raisons d'avoir
intégré ce projet, de nos différentes visions de l'avenir et surtout
de notre difficulté à faire partager tout ceci.
Nos différentes facettes sont je crois la force de SPIP et notre
difficulté à communiquer, à se (faire) comprendre notre faiblesse.

Je crois aussi que notre week end à Anthony avait pas mal aidé à
débroussailler le tout, peut être devrions nous réessayer.

Dernier point, concernant les évolutions : 2.1, 2.x, 3, ... Peut être
devrions nous nous faire un plan de route en se disant ça c'est pas
avant telle version et dépend de ça, ça et ça.

Je crois qu'on est en train de reproduire les mêmes erreurs que la
1.9.3 en attendant de tout sortir du corps pour la 2.1, peut être
pourrions nous le faire par étapes. Montrer une versions avec peut
etre une seule extension, puis la version d'apres avec 2,3 extensions,
.... (je crois qu'on avait gardé le terme extension pour les plugins
activés par défaut)
En ayant des sorties plus régulière cela nous évitera de nous lancer
dans des gros chantier bloquant comme on a pu l'avoir et comme j'ai
l'impression que cela arrive.

km

PS désolé pour ma mauvaise frappe, ici il fait dans les bureaux 15°,
l'horreur pour utiliser un clavier.