r12220 - in spip/ecrire: base public req

Author: cedric@yterium.com
Date: 2008-07-27 15:19:47 +0200 (dim, 27 jui 2008)
New Revision: 12220

Log:
Implementation des boucles pour:TABLEAU / for:TABLEAU
Sans aucune modification du compilateur, et en ajoutant un connecteur sur les donnees de type array, et la possibilite de definir une connexion par une fonction req_xxx_connect() au lieu d'un fichier config/xxx.php

Les champs utilisables sont #CLE et #VALEUR
Un critere {tableau xxx} permet de passer le tableau a parcourir :
il peut prendre tout tableau dans l'environnement : #ENV,#ENV{xxx},#GET{xxx},#EVAL{$GLOBALS},#EVAL{$GLOBALS['xxx']}

Un jeu de test bien utile pour montrer les fonctionnalites, incluant l'equivalent d'un var_dump sur un tableau a l'aide d'une boucle recursive :

<BOUCLE_test10(pour:TABLEAU){tableau #ENV}>
#CLE=>#VALEUR<br />
</BOUCLE_test10>
<hr />

<BOUCLE_test101(for:TABLEAU){tableau #ENV}>
#CLE=>#VALEUR<br />
</BOUCLE_test101>
<hr />

<BOUCLE_test11(pour:TABLEAU){tableau #EVAL{$GLOBALS['_ENV']}}>
#CLE=>#VALEUR<br />
</BOUCLE_test11>
<hr />

<BOUCLE_test12(pour:TABLEAU){tableau #ENV}{par cle}>
#CLE=>#VALEUR<br />
</BOUCLE_test12>
<hr />

<BOUCLE_test13(pour:TABLEAU){tableau #ENV}{!par cle}>
#CLE=>#VALEUR<br />
</BOUCLE_test13>
<BOUCLE_test14(pour:TABLEAU){tableau #ENV}{par valeur}>
#CLE=>#VALEUR<br />
</BOUCLE_test14>
<BOUCLE_test15(pour:TABLEAU){tableau #ENV}{!par valeur}>
#CLE=>#VALEUR<br />
</BOUCLE_test15>
<hr />

<B_test16>
<p>#PAGINATION</p>
<ul>
<BOUCLE_test16(pour:TABLEAU){tableau #EVAL{$GLOBALS}}{pagination}{par cle}>
<li>#CLE=>#VALEUR</li>
</BOUCLE_test16>
</ul>
</B_test16>
<hr />

<BOUCLE_test20(pour:TABLEAU){tableau #EVAL{$GLOBALS['_ENV']}}{cle=PATH}>
#CLE=>[(#VALEUR|var_export{1})]<br />
</BOUCLE_test20>
<hr />

<BOUCLE_test21(pour:TABLEAU){tableau #EVAL{$GLOBALS['_ENV']}}{cle==PATH}>
#CLE=>[(#VALEUR|var_export{1})]<br />
</BOUCLE_test21>
<hr />

<BOUCLE_test22(pour:TABLEAU){tableau #EVAL{$GLOBALS['_ENV']}}{cle IN (PATH,truc)}>
#CLE=>[(#VALEUR|var_export{1})]<br />
</BOUCLE_test22>
<hr />
<BOUCLE_test24(pour:TABLEAU){tableau #EVAL{$GLOBALS['_ENV']}}{valeur>a}>
#CLE=>[(#VALEUR|var_export{1})]<br />
</BOUCLE_test24>
<hr />

<B_test23>
<ul><li>
<BOUCLE_test23(pour:TABLEAU){tableau #EVAL{$GLOBALS}}>
#CLE=><B_test231><ul>
<BOUCLE_test231(pour:TABLEAU){tableau #VALEUR}><li>#CLE=><BOUCLE_test232(boucle_test231)></BOUCLE_test232></li></BOUCLE_test231>
</ul>
</B_test231>
#VALEUR</li><//B_test231>
</BOUCLE_test23>
</ul>
</B_test23>
<hr />

#SET{test,#ARRAY{1,2,3,4}}
<BOUCLE_test30(pour:TABLEAU){tableau #GET{test}}>
#CLE=>#VALEUR<br />
</BOUCLE_test30>
<hr />

Added:
   spip/ecrire/req/array.php
   spip/ecrire/req/for_connect.php
   spip/ecrire/req/pour_connect.php
Modified:
   spip/ecrire/base/connect_sql.php
   spip/ecrire/public/criteres.php

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

Je suis opposé à mettre dans la distrib quelque chose d'aussi dérogatoire à la vocation du répertoire ecrire/req et d'aussi peu abouti (countsel par exemple, n'est même pas présent). Je trouve quand même gros que tu puisses récriminer quand je fais des modifs qui tendent à minimiser le nombre de choses à savoir pour lire le code de SPIP (je parle ici de sql_count qui a disparu de l'espace privé), et que tu te permettes de balancer un concept nouveau de plusieurs Ko à qq jours d'une beta.

SPIP va crever à cause de ce genre de comportement: aucun concept nouveau, aucun ajout de code massif ne doit être entrepris sans un minimum de concertation permettant à tous de dire si l'ajout d'une nouvelle chose à apprendre ne va pas rendre SPIP un peu plus rébarbatif à ses utilisateurs présents ou futurs. Ce n'est pas seulement inacceptable de faire ça, c'est suicidaire.

Emmanuel

Cela ajoute un concept, effectivement, et surtout remplit un manque flagrant autour duquel tout le monde tourne depuis un moment.
A ce titre, la balise #FOREACH est couteuse en perfo par les multiples inclusions qu'elle provoque, et son maintien hasardeux (elle est bugguee actuellement, fait l'objet d'un ticket qu'on ne sait pas résoudre, et n'est utilisée que par le plugin nuage)

Les boucles sur tableau permettent par ailleurs une simplification et une accélération des modèles de pagination qui se réduisent à un seul calcul de squelette au lieu de 11 auparavant.
Le plugin de christian a été utilisé par pas mal de monde, mais avait le gros défaut d'introduire beaucoup de code dérogatoire dans le compilateur, rendant son intégration éventuelle au core difficile, et son maintien encore plus lourd.

Je suis conscient que cela arrive tard dans le process, et j'avais cela en chantier depuis un moment sans arriver à le finir.
On peut retirer le concept du core et le mettre en plugin, les seules modifications sur le code existant sont anecdotiques et ce ne sont pas elles qui risquent d'entraîner des bugs.

Sur le besoin en lui même d'avoir ce concept dans SPIP, je crois que cela est un fait avéré, qu'on le veuille ou non.

Après on peut discuter sur l'implémentation, ses avantages et ses inconvénients etc, et repousser l'intégration si vous préférez.
Rien n'oblige à la mettre dans la beta ni dans la stable 2.0.
Je peux admettre avoir dégainé trop tôt :stuck_out_tongue:

Le 27 juil. 08 à 15:46, Committo,Ergo:sum a écrit :

Je suis opposé à mettre dans la distrib quelque chose d'aussi dérogatoire à la vocation du répertoire ecrire/req et d'aussi peu abouti (countsel par exemple, n'est même pas présent). Je trouve quand même gros que tu puisses récriminer quand je fais des modifs qui tendent à minimiser le nombre de choses à savoir pour lire le code de SPIP (je parle ici de sql_count qui a disparu de l'espace privé), et que tu te permettes de balancer un concept nouveau de plusieurs Ko à qq jours d'une beta.

SPIP va crever à cause de ce genre de comportement: aucun concept nouveau, aucun ajout de code massif ne doit être entrepris sans un minimum de concertation permettant à tous de dire si l'ajout d'une nouvelle chose à apprendre ne va pas rendre SPIP un peu plus rébarbatif à ses utilisateurs présents ou futurs. Ce n'est pas seulement inacceptable de faire ça, c'est suicidaire.

Emmanuel

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

Le 27 juil. 08 à 16:13, cedric.morin@yterium.com a écrit :

Cela ajoute un concept, effectivement, et surtout remplit un manque flagrant autour duquel tout le monde tourne depuis un moment.

Tout le monde ? Pas moi en tout cas.

A ce titre, la balise #FOREACH est couteuse en perfo par les multiples inclusions qu'elle provoque, et son maintien hasardeux (elle est bugguee actuellement, fait l'objet d'un ticket qu'on ne sait pas résoudre, et n'est utilisée que par le plugin nuage)

Si sa sémantique est ingérable et qu'elle n'est utilisée que par un seul plugin, qu'on la retire de la distrib et qu'on la mette dans ce plugin. Ce n'est pas en accollant à un premier truc boiteux un deuxième truc boiteux qu'on obtient un système agréable à utiliser.

Les boucles sur tableau permettent par ailleurs une simplification et une accélération des modèles de pagination qui se réduisent à un seul calcul de squelette au lieu de 11 auparavant.

On peut aussi programmer directement en PHP, comme ça il y aura 0 squelettes à calculer, que demande le peuple ?

Sur le besoin en lui même d'avoir ce concept dans SPIP, je crois que cela est un fait avéré

NON. Le créneau de SPIP se sont les Webdesigners qui connaissent les formalismes graphiques du Web, contrairement aux utilsateurs de blogs clés 100% clé en main, mais ne maîtrisent pas la programmation. Le concept que tu proposes n'apportera rien aux programmeurs, car ils savent le programmer en PHP, et fera fuir les WebDesigners parce que ça demande de maîtriser de concepts de programmation.
Contrairement à ce que dit le proverbe, l'abondance de bien peut nuire.

Après on peut discuter sur l'implémentation, ses avantages et ses inconvénients etc, et repousser l'intégration si vous préférez.

"repousser" est un minimum.

Emmanuel

"repousser" est un minimum.

le maximum étant "j'irai les buter jusque dans les chiottes" du camarade Poutine

A mon sens on arrive au moment où la 2.0 bêta est prête à sortir (il
reste 1 bug qui entrave sa sortie, et il est tout petit), et ça
démange tout le monde de recommiter : je propose donc qu'on crée la
branche de stabilisation branches/SPIP-2.0/ sans le commit de Cédric,
de manière à pouvoir continuer à développer sans s'engueuler pour
savoir s'il est opportun ou pas de ceci ou de cela

-- Fil

Le 27 juil. 08 à 16:57, Fil a écrit :

A mon sens on arrive au moment où la 2.0 bêta est prête à sortir (il
reste 1 bug qui entrave sa sortie, et il est tout petit), et ça
démange tout le monde de recommiter : je propose donc qu'on crée la
branche de stabilisation branches/SPIP-2.0/ sans le commit de Cédric,
de manière à pouvoir continuer à développer sans s'engueuler pour
savoir s'il est opportun ou pas de ceci ou de cela

OK pour moi. J'ai qq soucis avec la version PG, pas sûr que je puisse m'en sortir en ne changeant que req/pg.php mais ce sera mineur si oui.

Emmanuel

Le 27 juil. 08 à 16:45, Committo,Ergo:sum a écrit :

Le 27 juil. 08 à 16:13, cedric.morin@yterium.com a écrit :

Cela ajoute un concept, effectivement, et surtout remplit un manque flagrant autour duquel tout le monde tourne depuis un moment.

Tout le monde ? Pas moi en tout cas.

A ce titre, la balise #FOREACH est couteuse en perfo par les multiples inclusions qu'elle provoque, et son maintien hasardeux (elle est bugguee actuellement, fait l'objet d'un ticket qu'on ne sait pas résoudre, et n'est utilisée que par le plugin nuage)

Si sa sémantique est ingérable et qu'elle n'est utilisée que par un seul plugin, qu'on la retire de la distrib et qu'on la mette dans ce plugin. Ce n'est pas en accollant à un premier truc boiteux un deuxième truc boiteux qu'on obtient un système agréable à utiliser.

Les boucles sur tableau permettent par ailleurs une simplification et une accélération des modèles de pagination qui se réduisent à un seul calcul de squelette au lieu de 11 auparavant.

On peut aussi programmer directement en PHP, comme ça il y aura 0 squelettes à calculer, que demande le peuple ?

C'était le cas avant, avec pour conséquence que cela ne convenait à personne, car chacun en voulait une version différente.
La c'est un modèle personnalisable, d'où l'intérêt du squelette.

Sur le besoin en lui même d'avoir ce concept dans SPIP, je crois que cela est un fait avéré

NON. Le créneau de SPIP se sont les Webdesigners qui connaissent les formalismes graphiques du Web, contrairement aux utilsateurs de blogs clés 100% clé en main, mais ne maîtrisent pas la programmation. Le concept que tu proposes n'apportera rien aux programmeurs, car ils savent le programmer en PHP, et fera fuir les WebDesigners parce que ça demande de maîtriser de concepts de programmation.
Contrairement à ce que dit le proverbe, l'abondance de bien peut nuire.

Dans SPIP, je lis
"SPIP 2, une plateforme de développement
Avec SPIP 2.0, nous initions donc un cycle de développements basés sur l’idée que, désormais, SPIP est une plateforme permettant le développement d’applications Web par les développeurs tiers."

Personnellement, c'est comme cela que je l'utilise de plus en plus, et à ce titre les boucles for/foreach sont le manque le plus criant du langage de squelette, qui nous obligent à faire des contorsions rendant rapidement le code lourd.
Pour reprendre le cas le plus répandu du nuage de tag, c'est à ce jour
- le plus souvent du code php dans les squelettes, exécuté à chaque hit, et le plus souvent présent sur les pages d'accueils
- parfois, lorsque le plugin nuage est utilise, un mélange de filtres, de #NUAGE, de #FOREACH, et de modèles de rendu dans lequel j'ai moi même eu du mal à atterrir

Alors, oui, on peut faire un #NUAGE|affiche_nuage dans lequel on va ecrire la mise semantique html en dur, mais on reperd la tout l'intérêt et le principe des squelettes et de leur personnalisation facile.

Cédric

Le 27 juil. 08 à 19:05, cedric.morin@yterium.com a écrit :

les boucles for/foreach sont le manque le plus criant du langage de squelette

Cher Cédric, je t'invite d'abord à réfléchir sur l'égocentrisme inconscient qu'il y a dans cette formule. TU ressens fortement ce manque dans TON utilisation de SPIP, TU entends peut-être plusieurs personnes TE dire qu'elles le ressentent aussi, rien de plus, rien de moins.

SPIP est un travail collectif, et ce qui change sa physionomie doit être discuté en commun un minimum avant d'être diffusé. Ne pas respecter ça a suffisamment amené de conflits cassant la dynamique de l'équipe pour qu'on s'interdise de le faire désormais.

Ensuite, il faut bien voir que tout ajout, même parfaitement réalisé, n'est pas nécessairement bon à prendre. Un outil n'est utilisé que si les gens arrivent à se faire rapidement une représentation de comment il fonctionne. Cette représentation peut-être fausse, l'essentiel est que ça leur permette de se l'approprier (l'écrasante majorité des gens ne sait pas comment fonctionne leur mailer, mais la représentation qu'ils s'en font leur suffit à sentir qu'ils dominent l'outil). Et pour que ce sentiment de dominer l'outil s'installe rapidement, il faut limiter le plus possible les concepts, et éviter qu'un concept apparamment compris se révèle plus tard inmaitrisable car bourré d'exceptions.

En l'occurrence, le premier problème du dépot 12220 est qu'il obscurcit la représentation qu'on peut se faire du répertoire ecrire/req: il est censé offrir un jeu COMPLET de requêtes écrites dans un LANGAGE décrit par une DOCUMENTATION officielle. Le dépot 12220 viole les 3 points écrits en majuscules, c'est pourquoi c'est une bidouille qui n'a pas sa place dans la distrib officielle quel qu'en soit l'intérêt.

Aujourd'hui le principal discours (il y a plein d'autres choses hein, mais je parle de l'aspect général) à faire passer est : aujourd'hui SPIP est plus que le générateur de blog collectif qu'il a toujours été (ça c'est la réprésentation qui a fait son succès jurqu'à présent), c'est AUSSI un système de publication de bases de données hétérogènes qui continue à ne demander aucune connaissance en programmation pour personnaliser la mise en page de ces données malgré ce saut technique. Il faut donc viser à REDUIRE le nombre de concepts dans SPIP (le jargon de SPIP est effrayant de longueur et d'ambiguités), pas en rajouter.

Alors une solution au pb technique que tu cherches à résoudre est peut-être effectivement attendue avec impatience par une grande majorité des utilisateurs de SPIP, admettons, mais elle doit être trouvée à l'aide des concepts existants, ou permettre d'en supprimer au moins un.
Si on ne s'impose pas cette discipline, SPIP va devenir aussi difforme que le pire des systèmes d'exploitation qui sévit sur les PC, ce n'est pas souhaitable.

Emmanuel

Committo,Ergo:sum a écrit :

Le 27 juil. 08 à 19:05, cedric.morin@yterium.com a écrit :

les boucles for/foreach sont le manque le plus criant du langage de squelette

Cher Cédric, je t'invite d'abord à réfléchir sur l'égocentrisme inconscient qu'il y a dans cette formule. TU ressens fortement ce manque dans TON utilisation de SPIP, TU entends peut-être plusieurs personnes TE dire qu'elles le ressentent aussi, rien de plus, rien de moins.

Je m'immisce dans la discussion un petit peu.

Je ne pense pas du tout que ce soit de l'égocentrisme de la part de Cédric que de chercher une solution à ce problème rencontré. Ce n'est pas un problème nouveau (Piif avait déjà permis cela avec le plugin boucles sans tables), et c'est un problème toujours d'actualité.

Je fais partis des gens qui aimeraient réaliser des boucles sur d'autres choses que sur une base de donnée SQL, et à ce titre, du XML ou un tableau PHP est une base de donnée aussi.

A l'heure où PHP sait faire du foreach() sur du XML, des tableaux PHP ou tout objet, il est dommage que SPIP ne permette pas de traduire facilement ce concept de boucle dans la syntaxe qui en fait toute sa force, les <BOUCLES />

Sur la liste spip.zone, et plus généralement sur l'IRC pour les gens qui cherchent des informations pour fabriquer des plugins (ils sont de plus en plus nombreux ce qui est un excellent signe), il y a des demandes sur "comment on boucle un tableau php en SPIP" ? C'est d'une évidence frappante : on cherche à mixer les 2 forces des outils PHP et SPIP... à PHP les calculs (de tableaux), à SPIP l'affichage...

Je n'ose pas les orienter sur #FOREACH qui est inaccessible au commun des programmeurs (en plus de provoquer d'énormes calculs de squelettes). Le plugin de Piif a de bons atouts, par exemple le fait de pouvoir faire une boucle sur le résultat d'une fonction PHP (ce que ne semble pas proposer l'implémentation de cédric. - rectification #VAL|fonction doit marcher avec son implementation).

Je pense aussi que ca ne devait peut-être pas rentrer dans SPIP 2.0 à quelques jours de la béta... Mais, bon, comme la béta n'est pas encore sortie !!
...

Alors une solution au pb technique que tu cherches à résoudre est peut-être effectivement attendue avec impatience par une grande majorité des utilisateurs de SPIP, admettons, mais elle doit être trouvée à l'aide des concepts existants, ou permettre d'en supprimer au moins un.

Maintenant, en quoi utiliser req/xx.php crée-t-il de l'entropie ? n'est-ce pas utiliser un concept existant que de permettre d'utiliser req/ comme une interface d'accès à des éléments d'une base de données (sql ou non) ?

Que telle où telle solution soit retenue plus qu'une autre, cela m'est égal, mais il serait bien, un jour, de réussir à proposer cela. Il me semblait (aussi pourtant) que req/ était l'endroit approprié pour un tel interfaçage...

Qu'elles seraient les autres possibilités pour apporter cette fonctionnalité à SPIP ?

----

Pour revenir à l'implementation même, je pense Cédric qu'il faudrait aussi pouvoir réaliser, avec des tableaux multidimentionnels array(array('nom'=>val,'adresse'=>val,'cp'=>val)) une utilisation dans un langage plus naturel :

<BOUCLE_t(for:TABLEAU){tableau (#VAL|fonction)}>
#NOM - #ADRESSE - #CP<br />
</BOUCLE>

C'était mes petites impressions d'un lundi matin, encore un peu fatigué !
--
MM.

Le 28 juil. 08 à 07:52, Matthieu Marcillaud a écrit :

les boucles for/foreach sont le manque le plus criant du langage de squelette

Cher Cédric, je t'invite d'abord à réfléchir sur l'égocentrisme inconscient qu'il y a dans cette formule. TU ressens fortement ce manque dans TON utilisation de SPIP, TU entends peut-être plusieurs personnes TE dire qu'elles le ressentent aussi, rien de plus, rien de moins.

Je ne pense pas du tout que ce soit de l'égocentrisme de la part de Cédric que de chercher une solution à ce problème rencontré.

Je ne parlais pas du travail effectué, qui a son intérêt, mais du manque de distance par rapport à ce qui a motivé son dépot dans la distrb' sans concertation.

Maintenant, en quoi utiliser req/xx.php crée-t-il de l'entropie ? n'est-ce pas utiliser un concept existant que de permettre d'utiliser req/ comme une interface d'accès à des éléments d'une base de données (sql ou non) ?

Ce n'est pas le fait de l'utiliser, c'est la manière. Normalement s'il existe le fichier req/X.php c'est qu'il existe le jeu complet de fonctions d'interface à un gestionnaire de BD nommé X, à commencer par la fonction de connexion à ce gestionnaire. Là on a 3 fichiers (pour, for, array) qui définissent les fonctions pour_connect et for_connect mais pas array_connect, et pour les autres fonctions c'est à l'avenant. Moi j'appelle ça rajouter de l'entropie.

Cédric, j'apprécie les fonctionnalités que tu amènes à SPIP, mais je déplore que cela se fasse si souvent par une désorganisation du code. SPIP n'est pas seulement un outil clé en main pour blogueur, c'est un système dont le code doit être organisé de sorte qu'il soit facile d'y pénétrer et de devenir contributeur. Les fichiers du compilateur en 1.9.2 étaient essentiellement inclus par des appels à charger_fontion, ça permettait facilement leur surcharge. La possibilité de compiler de l'AJAX a foutu ça en l'air. Je n'ai rien dit parce que la fonctionnalité est importante, mais je déplore cette regression. Il n'est pas acceptable qu'à présent tu mettes le bordel dans le répertoire req pour une fonctionnalité marginale, de surcroit à la veille de la sortie d'une beta.
Ces fichiers doivent donc être retirés sans délai.

Qu'elles seraient les autres possibilités pour apporter cette fonctionnalité à SPIP ?

L'absence de cette fonctionnalité n'est absolument pas criante pour moi, je n'ai donc pas réfléchi à la question. Mais je répète qu'il y a une question de principe: si l'ajout d'une fonctionnalité apporte plus de préjudices à SPIP que d'améliorations, elle ne doit pas être intégrée.

Emmanuel

Il est entendu que la fonctionnalité et ses fichiers ne seront pas dans la 2.0.

Maintenant, sur le détail de l'implémentation je note tes arguments :

- n'utiliser les public/xxx que par l'intermediaire de charger_fonction() -> il est simple de deplacer la fonction traiter_formulaires_dynamiques() vers une fonction public_traiter_forumaires_dynamiques_dist(), et de nettoyer la quinzaine d'inclusion directe de public/assembler en passant toujours par evaluer_fond() de inc/utils

- les fonctions for_connect() et pour_connect(), n'ont rien a faire dans req/. Il est vrai qu'elles ne sont pas homogènes avec les autres. On peut dans ce cas leur attribuer un repertoire connect/. Ce besoin n'est pas limité à la boucle for/pour : a titre d'exemple, il n'est pas possible de distribuer un plugin face_boucle permettant de boucler sur les données de face book au format FQL (directement inspiré de SQL) car la connexion necessite un fichier xxx.php placé dans config/ qui doit être copié à la main, ce qui va à l'encontre même du principe de plugin.
Es-tu d'accord avec le nom de repertoire connect/ pour ranger ces fonctions de connexions ?

- req/array fournit une couche d'interface entre les fonctions sql_xx et les fonctions de manipulation de tableau du LANGAGE php DOCUMENTE. Et si l'implémentation n'est pas COMPLETE, c'est un oubli que je veux bien réparer.
La seul bidouille en question est de ne pas passer le array(...) en question dans la clause from sous la forme $from=array('tableau'=>array(...donnees....)). Je vais donc m'atteler à corriger cela afin que la coherence du tout soit assurée.

Sur la représentation que les gens peuvent de faire du répertoire req/, je ne crois pas que cette représentation s'adresse au commun des utilisateurs, mais qu'elle concerne uniquement des développeurs ayant un certain niveau de compréhension. Je ne vois pas en quoi il est bloquant d'avoir un connecteur sql_xx -> array() dans ce répertoire, même si c'est effectivement une généralisation de ce pour quoi tu l'avais imaginé initialement.

Sur le fond du débat, et le manque supposé ou avéré, je ne ferais que re-citer l'article "Pourquoi SPIP 2" qui revendique haut et fort le fait que Spip a maintenant aussi vocation à être une plateforme de développement d'application Web.

- Soit on est cohérent et on cherche à combler les manques de Spip en tant que plateforme de développement. A ce titre, les structures FOR/FOREACH/IF sont les manques les plus récurrents.
- Soit on dit qu'on ne veut pas introduire ces concepts, et je crois qu'il vaudrait mieux revoir nos fanfaronnades à la baisse. Car honnêtement, une plate-forme de développement revendiquée comme telle qui oblige à faire des contorsions pour parcourir un tableau, itérer, ou faire une condition, cela parait bien pauvre.

Cédric

Le 28 juil. 08 à 08:53, Committo,Ergo:sum a écrit :

Le 28 juil. 08 à 07:52, Matthieu Marcillaud a écrit :

les boucles for/foreach sont le manque le plus criant du langage de squelette

Cher Cédric, je t'invite d'abord à réfléchir sur l'égocentrisme inconscient qu'il y a dans cette formule. TU ressens fortement ce manque dans TON utilisation de SPIP, TU entends peut-être plusieurs personnes TE dire qu'elles le ressentent aussi, rien de plus, rien de moins.

Je ne pense pas du tout que ce soit de l'égocentrisme de la part de Cédric que de chercher une solution à ce problème rencontré.

Je ne parlais pas du travail effectué, qui a son intérêt, mais du manque de distance par rapport à ce qui a motivé son dépot dans la distrb' sans concertation.

Maintenant, en quoi utiliser req/xx.php crée-t-il de l'entropie ? n'est-ce pas utiliser un concept existant que de permettre d'utiliser req/ comme une interface d'accès à des éléments d'une base de données (sql ou non) ?

Ce n'est pas le fait de l'utiliser, c'est la manière. Normalement s'il existe le fichier req/X.php c'est qu'il existe le jeu complet de fonctions d'interface à un gestionnaire de BD nommé X, à commencer par la fonction de connexion à ce gestionnaire. Là on a 3 fichiers (pour, for, array) qui définissent les fonctions pour_connect et for_connect mais pas array_connect, et pour les autres fonctions c'est à l'avenant. Moi j'appelle ça rajouter de l'entropie.

Cédric, j'apprécie les fonctionnalités que tu amènes à SPIP, mais je déplore que cela se fasse si souvent par une désorganisation du code. SPIP n'est pas seulement un outil clé en main pour blogueur, c'est un système dont le code doit être organisé de sorte qu'il soit facile d'y pénétrer et de devenir contributeur. Les fichiers du compilateur en 1.9.2 étaient essentiellement inclus par des appels à charger_fontion, ça permettait facilement leur surcharge. La possibilité de compiler de l'AJAX a foutu ça en l'air. Je n'ai rien dit parce que la fonctionnalité est importante, mais je déplore cette regression. Il n'est pas acceptable qu'à présent tu mettes le bordel dans le répertoire req pour une fonctionnalité marginale, de surcroit à la veille de la sortie d'une beta.
Ces fichiers doivent donc être retirés sans délai.

Qu'elles seraient les autres possibilités pour apporter cette fonctionnalité à SPIP ?

L'absence de cette fonctionnalité n'est absolument pas criante pour moi, je n'ai donc pas réfléchi à la question. Mais je répète qu'il y a une question de principe: si l'ajout d'une fonctionnalité apporte plus de préjudices à SPIP que d'améliorations, elle ne doit pas être intégrée.

Emmanuel

Le 28 juil. 08 à 10:53, cedric.morin@yterium.com a écrit :

- n'utiliser les public/xxx que par l'intermediaire de charger_fonction() -> il est simple de deplacer la fonction traiter_formulaires_dynamiques() vers une fonction public_traiter_forumaires_dynamiques_dist(), et de nettoyer la quinzaine d'inclusion directe de public/assembler en passant toujours par evaluer_fond() de inc/utils

Bon, bonne nouvelle, si c'est simple il faut le faire. Je n'ai pas regardé plus en détail l'évolution du compilateur, mais déjà que son code est difficile, il faut essayer de garder une architecture générale lisible (c'est-à-dire éviter les inclusions dans tous les sens).

- les fonctions for_connect() et pour_connect(), n'ont rien a faire dans req/. Il est vrai qu'elles ne sont pas homogènes avec les autres. On peut dans ce cas leur attribuer un repertoire connect/. Ce besoin n'est pas limité à la boucle for/pour : a titre d'exemple, il n'est pas possible de distribuer un plugin face_boucle permettant de boucler sur les données de face book au format FQL (directement inspiré de SQL) car la connexion necessite un fichier xxx.php placé dans config/ qui doit être copié à la main, ce qui va à l'encontre même du principe de plugin.

Je ne comprends pas cet argument. Pour se connecter à un serveur SQL, SPIP demande des infos et crée le fichier dont le nom est donné par _FILE_CONNECT. Ces infos sont demandées à l'install, ou bien ultérieurement lorsqu'on déclare des bases annexes. Si un plugin veut utiliser SPIP pour le connecter à un pseudo serveur SQL, il doit offrir un mécanisme créant ce fichier, éventuellement en utilisant le code dé déclaration de bases annexes (il y a eu opposition à mon architecture initiale de déclarer ces bases à l'install; puisqu'un code a été développé spécifiquement pour la création d'un tel fichier à tout moment, ce serait l'occasion de faire la preuve de son utilité).

Es-tu d'accord avec le nom de repertoire connect/ pour ranger ces fonctions de connexions ?

Je ne suis pas sûr de comprendre le problème dont je répète qu'il n'est nullement criant pour moi, mais j'ai l'impression que ceci ferait double emploi avec le répertoire des fichiers de connexion aux bases annexes.

- req/array fournit une couche d'interface entre les fonctions sql_xx et les fonctions de manipulation de tableau du LANGAGE php DOCUMENTE.

NON. Cette interface ne concerne qu'un tout petit sous-ensemble de PHP, il n'existe donc pas de documentation dessus. Un langage se définit par son lexique et sa grammaire limités aux seules choses autorisées. Un dictionnaire contenant tous les mots des langues issues du latin est inutilisable en tant que dictionnaire du français. C'est pas possible ce mépris que tu as pour la rédaction précise des docs.

Et si l'implémentation n'est pas COMPLETE, c'est un oubli que je veux bien réparer.
La seul bidouille en question est de ne pas passer le array(...) en question dans la clause from sous la forme $from=array('tableau'=>array(...donnees....)). Je vais donc m'atteler à corriger cela afin que la coherence du tout soit assurée.

Je doute que cette cohérence soit atteignable en quelques jours, je trouve donc hallucinant de lancer un tel chantier alors qu'on était d'accord pour annoncer la beta le plus tôt possible. Redépose tout ça dans un plugin, et on en reparlera quand il aura atteint un niveau de cohérence et de complétude suffisant.

Sur la représentation que les gens peuvent de faire du répertoire req/, je ne crois pas que cette représentation s'adresse au commun des utilisateurs, mais qu'elle concerne uniquement des développeurs ayant un certain niveau de compréhension.

NON. Le contenu des fichiers d'un répertoire est une chose, l'organisation de celui-ci en est une autre. Le premier s'adresse aux développeurs, la deuxième s'adresse à tout le monde.

Je ne vois pas en quoi il est bloquant d'avoir un connecteur sql_xx -> array() dans ce répertoire, même si c'est effectivement une généralisation de ce pour quoi tu l'avais imaginé initialement.

L'annonce qu'on comptait faire est que SPIP est multi-serveur SQL, pas qu'il est multi-n'importe-quelle-structure-de-données. Cette nouvelle généralisation ne s'improvise pas à quelques jours d'une beta par une décision unilatérale d'une seule personne. Elle est simplement inopportune à l'instant présent.

Sur le fond du débat, et le manque supposé ou avéré, je ne ferais que re-citer l'article "Pourquoi SPIP 2" qui revendique haut et fort le fait que Spip a maintenant aussi vocation à être une plateforme de développement d'application Web.

- Soit on est cohérent et on cherche à combler les manques de Spip en tant que plateforme de développement. A ce titre, les structures FOR/FOREACH/IF sont les manques les plus récurrents.
- Soit on dit qu'on ne veut pas introduire ces concepts, et je crois qu'il vaudrait mieux revoir nos fanfaronnades à la baisse. Car honnêtement, une plate-forme de développement revendiquée comme telle qui oblige à faire des contorsions pour parcourir un tableau, itérer, ou faire une condition, cela parait bien pauvre.

Il y a mille autres choses qui manque encore à SPIP dans cette version, tu n'es pas la seul à regretter que telle ou telle chose n'y figure pas. Il faut simplement dire STOP à un moment, sinon on ne sortira jamais cette version.

Emmanuel

Heureusement que j'avais commencé mon mail par
"Il est entendu que la fonctionnalité et ses fichiers ne seront pas dans la 2.0." :stuck_out_tongue:

Sur le point précis du fichier de connexion config/xxx, le répertoire config/ n'est pas garanti comme étant accessible en écriture en dehors de l'installation.
L'installation d'un fichier dans ce répertoire lors de l'installation d'un plugin n'est donc pas un processus garanti. Je veux bien m'en contenter si on change ce pré-requis.

Le 28 juil. 08 à 11:38, Committo,Ergo:sum a écrit :

Le 28 juil. 08 à 10:53, cedric.morin@yterium.com a écrit :

- n'utiliser les public/xxx que par l'intermediaire de charger_fonction() -> il est simple de deplacer la fonction traiter_formulaires_dynamiques() vers une fonction public_traiter_forumaires_dynamiques_dist(), et de nettoyer la quinzaine d'inclusion directe de public/assembler en passant toujours par evaluer_fond() de inc/utils

Bon, bonne nouvelle, si c'est simple il faut le faire. Je n'ai pas regardé plus en détail l'évolution du compilateur, mais déjà que son code est difficile, il faut essayer de garder une architecture générale lisible (c'est-à-dire éviter les inclusions dans tous les sens).

- les fonctions for_connect() et pour_connect(), n'ont rien a faire dans req/. Il est vrai qu'elles ne sont pas homogènes avec les autres. On peut dans ce cas leur attribuer un repertoire connect/. Ce besoin n'est pas limité à la boucle for/pour : a titre d'exemple, il n'est pas possible de distribuer un plugin face_boucle permettant de boucler sur les données de face book au format FQL (directement inspiré de SQL) car la connexion necessite un fichier xxx.php placé dans config/ qui doit être copié à la main, ce qui va à l'encontre même du principe de plugin.

Je ne comprends pas cet argument. Pour se connecter à un serveur SQL, SPIP demande des infos et crée le fichier dont le nom est donné par _FILE_CONNECT. Ces infos sont demandées à l'install, ou bien ultérieurement lorsqu'on déclare des bases annexes. Si un plugin veut utiliser SPIP pour le connecter à un pseudo serveur SQL, il doit offrir un mécanisme créant ce fichier, éventuellement en utilisant le code dé déclaration de bases annexes (il y a eu opposition à mon architecture initiale de déclarer ces bases à l'install; puisqu'un code a été développé spécifiquement pour la création d'un tel fichier à tout moment, ce serait l'occasion de faire la preuve de son utilité).

Es-tu d'accord avec le nom de repertoire connect/ pour ranger ces fonctions de connexions ?

Je ne suis pas sûr de comprendre le problème dont je répète qu'il n'est nullement criant pour moi, mais j'ai l'impression que ceci ferait double emploi avec le répertoire des fichiers de connexion aux bases annexes.

- req/array fournit une couche d'interface entre les fonctions sql_xx et les fonctions de manipulation de tableau du LANGAGE php DOCUMENTE.

NON. Cette interface ne concerne qu'un tout petit sous-ensemble de PHP, il n'existe donc pas de documentation dessus. Un langage se définit par son lexique et sa grammaire limités aux seules choses autorisées. Un dictionnaire contenant tous les mots des langues issues du latin est inutilisable en tant que dictionnaire du français. C'est pas possible ce mépris que tu as pour la rédaction précise des docs.

Et si l'implémentation n'est pas COMPLETE, c'est un oubli que je veux bien réparer.
La seul bidouille en question est de ne pas passer le array(...) en question dans la clause from sous la forme $from=array('tableau'=>array(...donnees....)). Je vais donc m'atteler à corriger cela afin que la coherence du tout soit assurée.

Je doute que cette cohérence soit atteignable en quelques jours, je trouve donc hallucinant de lancer un tel chantier alors qu'on était d'accord pour annoncer la beta le plus tôt possible. Redépose tout ça dans un plugin, et on en reparlera quand il aura atteint un niveau de cohérence et de complétude suffisant.

Sur la représentation que les gens peuvent de faire du répertoire req/, je ne crois pas que cette représentation s'adresse au commun des utilisateurs, mais qu'elle concerne uniquement des développeurs ayant un certain niveau de compréhension.

NON. Le contenu des fichiers d'un répertoire est une chose, l'organisation de celui-ci en est une autre. Le premier s'adresse aux développeurs, la deuxième s'adresse à tout le monde.

Je ne vois pas en quoi il est bloquant d'avoir un connecteur sql_xx -> array() dans ce répertoire, même si c'est effectivement une généralisation de ce pour quoi tu l'avais imaginé initialement.

L'annonce qu'on comptait faire est que SPIP est multi-serveur SQL, pas qu'il est multi-n'importe-quelle-structure-de-données. Cette nouvelle généralisation ne s'improvise pas à quelques jours d'une beta par une décision unilatérale d'une seule personne. Elle est simplement inopportune à l'instant présent.

Sur le fond du débat, et le manque supposé ou avéré, je ne ferais que re-citer l'article "Pourquoi SPIP 2" qui revendique haut et fort le fait que Spip a maintenant aussi vocation à être une plateforme de développement d'application Web.

- Soit on est cohérent et on cherche à combler les manques de Spip en tant que plateforme de développement. A ce titre, les structures FOR/FOREACH/IF sont les manques les plus récurrents.
- Soit on dit qu'on ne veut pas introduire ces concepts, et je crois qu'il vaudrait mieux revoir nos fanfaronnades à la baisse. Car honnêtement, une plate-forme de développement revendiquée comme telle qui oblige à faire des contorsions pour parcourir un tableau, itérer, ou faire une condition, cela parait bien pauvre.

Il y a mille autres choses qui manque encore à SPIP dans cette version, tu n'es pas la seul à regretter que telle ou telle chose n'y figure pas. Il faut simplement dire STOP à un moment, sinon on ne sortira jamais cette version.

Emmanuel

cedric.morin@yterium.com a écrit :

Heureusement que j'avais commencé mon mail par
"Il est entendu que la fonctionnalité et ses fichiers ne seront pas dans la 2.0." :stuck_out_tongue:

Sur le point précis du fichier de connexion config/xxx, le répertoire config/ n'est pas garanti comme étant accessible en écriture en dehors de l'installation.
L'installation d'un fichier dans ce répertoire lors de l'installation d'un plugin n'est donc pas un processus garanti. Je veux bien m'en contenter si on change ce pré-requis.

Je repense à un point qu'abordait Fil sur irc je ne sais plus quand : un plugin pourrait très bien fournir une base de donnée SQLite, par exemple de code postaux géographiques.

Comment ce plugin peut-il simplement appeler sa base de donnée SQLite ?
Il faut je crois 2 choses :
1) préfixer les tables par le nom du fichier de connexion <BOUCLE_v(geo:VILLES)/> par exemple
2) fournir un moyen de se connecter à 'geo' et c'est là où on revient sur l'histoire souligné de FACEBOUCLE, un peu similaire. Soit c'est l'utilisateur qui crée manuellement le connecteur (via l'interface prévue), soit c'est le plugin lui-même qui le crée ou qui (mieux je pense) propose directement un moyen de s'y connecter (je n'ai pas réfléchis à comment).

Je crois comprendre que l'idée du répertoire connect/ est un peu cela ?

--
MM.

Je trouve que tu y vas un peu fort dans ta manière de rejeter ce que
Cédric a fait. On n'a pas tous les mêmes priorités au même moment, on
ne programme pas tous de la même manière, et s'il faut essayer de
converger autant que possible ce n'est pas en assenant des priorités
personnelles (pourquoi le portage en PG serait-il plus important que
le connecteur Facebook ? ou l'inverse ?), et surtout des supériorités
et des certitudes "d'en haut" que ça va pouvoir marcher.

(La remarque est vraie pour ARNO* aussi, et s'applique aussi sans
doute à moi, j'imagine, ne serait-ce que dans ce mail).

Pour prendre un exemple, puisque tu le cites, le fameux
charger_fonction() a été introduit unilatéralement et au mépris d'une
méthode existante (les "pipeline" dont tu as toujours dit que c'était
de la mauvaise programmation) ; or s'il était clair que
charger_fonction permettait la *surcharge* (qui était déjà possible),
il ne faisait aucun cas de l'extensibilité par plugins (censés aussi
"ne jamais marcher", si mes souvenirs sont bons), puisqu'on ne peut
faire qu'une surcharge unique avec ce fameux charger_fonction().

Pour ma part, il y a beaucoup de choses que je n'aime pas dans le code
que vous produisez, l'un comme l'autre. Manque de jeux de tests,
manque de documentation, ponctuation défectueuse, etc. Mais j'aime le
résultat (ça marche, et bien), et j'aime surtout le fait qu'on peut se
parler et dire "tiens là tu as un truc pas clair", qu'on ne se fait
pas jeter quand on travaille sur le code des autres, et que du coup on
s'améliore ensemble. Ca, c'est précieux.

-- Fil

Le 28 juil. 08 à 14:15, Fil a écrit :

Je trouve que tu y vas un peu fort dans ta manière de rejeter ce que
Cédric a fait. On n'a pas tous les mêmes priorités au même moment, on
ne programme pas tous de la même manière, et s'il faut essayer de
converger autant que possible ce n'est pas en assenant des priorités
personnelles (pourquoi le portage en PG serait-il plus important que
le connecteur Facebook ? ou l'inverse ?),

Je n'ai jamais dit que l'un est plus important que l'autre,
et je répète que mon grief principal est sur la forme:
quand j'ai décidé il y a un an de me lancer dans le portage PG,
j'ai d'abord commencé par vous le dire voir ce que vous en pensiez,
j'ai dit aussi qu'on pourrait sortir une nouvelle version au 1er Octobre 2007,
en présentant SPIP-PG comme expérimental.
Je ne me suis jamais permis des dépots bouleversant l'architecture sans prévenir.

et surtout des supériorités
et des certitudes "d'en haut" que ça va pouvoir marcher.

??? Ce que j'ai développé, c'est moins SPIP-PG qu'une architecture générale de portage au final assez proche du sql_alchimy en Python ou du JDBC,
donc quelque chose qui "va pouvoir marcher" parce que c'est assez standard comme méthode de développement.
Cette architecture en a d'ailleurs permis d'autres immédiatement (cf SQLite par Mathieu), Oracle est aussi en bonne voie,
ce n'est donc pas PG en soi qui est important
(au passage, je suis revenu à SPIP-MySQL pour mon site en prod pour cause de mauvaises perfs de SPIP-PG, sans trop savoir si c'est dû à la charge de PG hors SPIP ou pas)
mais la rationnalisation du code que ce travail a induit, facilitant d'autres développements.

(La remarque est vraie pour ARNO* aussi, et s'applique aussi sans
doute à moi, j'imagine, ne serait-ce que dans ce mail).

Pour prendre un exemple, puisque tu le cites, le fameux
charger_fonction() a été introduit unilatéralement et au mépris d'une
méthode existante (les "pipeline" dont tu as toujours dit que c'était
de la mauvaise programmation) ; or s'il était clair que
charger_fonction permettait la *surcharge* (qui était déjà possible),
il ne faisait aucun cas de l'extensibilité par plugins (censés aussi
"ne jamais marcher", si mes souvenirs sont bons), puisqu'on ne peut
faire qu'une surcharge unique avec ce fameux charger_fonction().

L'histoire n'est pas aussi limpide que tu le dis.
J'ai mis en chantier une réécriture à coup double, savoir la mutualisation et la surcharge.
Ce doublé était un plus gros chantier qui s'est terminé plus tard que celui consistant à rajouter des points d'entrée ici ou là,
mais qui a démarré plus tôt, du moins dans mon esprit (et je crois aussi pour les dates de dépot, mais ça n'a pas grande importance de toutes façons).
J'attends toujours qu'on me montre des exemples de deux plugins qui composent des pipelines avec le résultat souhaité sans qu'il y ait eu besoin d'aller voir le code pour régler leur composition.
En outre, je n'aurais probablement pas finalisé le charger_fonction telle qu'il est finalement si justement les pipe-line n'avaient pas fait leur apparition entretemps:
les deux concepts sont redondants, mais j'ai laissé tomber la réflexion en attendant que d'autres manières de travail soient ressenties par tout le monde comme nécessaires.

Maitentant, sur le fait que j'étais sceptique sur l'avenir des plugins, tout dépend de ce qu'on appelle "marcher".
Que l'opération "plugin" ait été une réussite "sociale", c'est certain et j'ai déjà dit (et donc je le redis) que j'ai été trop frileux dans mon positionnement de l'époque, consitant à dire "l'API n'est pas mûre, ça va être le souk". Mais les récriminations perpétuelles sur les plugins non compatibles entre 1.9.1 et 1.9.2 et SVN montrent que dans cette histoire,
nous avions tous raison (ou tous tort, comme on veut).

Pour ma part, il y a beaucoup de choses que je n'aime pas dans le code
que vous produisez, l'un comme l'autre. Manque de jeux de tests,
manque de documentation, ponctuation défectueuse, etc.

En ce qui concerne la documentation, ce n'est pas mon cas.
Si tu parles des commentaires (ce n'est pas la même chose),
j'ai déjà dit que bien souvent ils n'apportaient rien car ils commentent le texte et non le contexte,
et pratiquement tous les commentaires du code de SPIP sont ainsi malheureuseument.

Un contre-exemple: j'avais ouvert la tâche 605 "migrer les accès en écriture dans le répertoire action".
Ce ticket donnait un contexte plus éclairant de tous les dépots qui allaient suivre que des commentaires ici ou là.
J'ai fini par comprendre que tu avais décidé de faire une API de modif, très bonne au demeurant sur le fond, mais qui n'était pas sans contredire la forme annoncée par la tâche 605.
As-tu pris la peine de l'écrire clairement, sur le ticket ou ailleurs ? Non. Alors je trouve un peu gros de récriminer sur le manque d'info que je donnerais sur mes activités.

Mais j'aime le
résultat (ça marche, et bien), et j'aime surtout le fait qu'on peut se
parler et dire "tiens là tu as un truc pas clair", qu'on ne se fait
pas jeter quand on travaille sur le code des autres, et que du coup on
s'améliore ensemble. Ca, c'est précieux.

Oui, tout à fait, et c'est pour ça que je m'accroche malgré, comme je vous ai dit, d'autres fronts qui se sont ouverts depuis un an.
Je ne suis pas en pétard, hein, juste impatient qu'on sorte enfin cette version, qu'on puisse rassurer la communauté sur la perennité de SPIP,
et qu'il soit utilisé pour, entre autres justement, ces autres fronts.

Amitiés, à tous,

Emmanuel

Le 28 juil. 2008 à 14:15, Fil a écrit :

et j'aime surtout le fait qu'on peut se
parler et dire "tiens là tu as un truc pas clair", qu'on ne se fait
pas jeter quand on travaille sur le code des autres, et que du coup on
s'améliore ensemble. Ca, c'est précieux.

Merci de nous le rappeler.

--
Romy