[spip-dev] deux ou trois problèmes avec le compilo

[fil]

En SPIP 2.1 j'ai plein de problèmes avec le compilo. Je me trompe
peut-être car je ne comprends pas comment on n'avait pas vu ça avant.

* 1 Contrairement à "la spec", les balises ne "bouffent" plus les
sauts de ligne situés après elles :

#CACHE{0}
Salut
    => provoque un saut de ligne avant le mot "Salut"

* 2 Il n'est plus possible d'activer ?var_mode=debug sur ?page=sitemap.xml

* 3 Une balise inconnue mais ayant un paramètre provoque un
dédoublement du texte qui la suit. Squelette de test :

#RIEN{1}
coucou

=> affiche "coucou coucou"

-- Fil

[esj]

Pour les 2 premiers j'ai vu et c'est corrigé.

Pour le 3e, je peux envoyer une solution, mais il y aura intérêt à tester intensivement car on est dans la zone des cas pathologiques et ça risque de faire pire ailleurs. Pas sûr que ce soit une bonne idée de corriger qqch d'anormal de toutes façons.

Committo,Ergo:Sum

[lspeciale (Luis Speciale)]

Committo,Ergo:sum a écrit :

car on est dans la zone des cas pathologiques et ça risque de faire pire ailleurs. Pas sûr que ce soit une bonne idée de corriger qqch d'anormal de toutes façons.

Polatouches, peut-être, neo-behavioristes jamais !

A +

Luis

[esj]

Bon, ça a l'air correct, j'ai envoyé.

J'en profite pour rappeller que le message suivant:
http://article.gmane.org/gmane.comp.web.spip.devel/57708/
reste sans réponse depuis 10 jours, pour ne pas dire 15 puisque c'est toujours le même point en discussion.
C'est 3 fois rien mais ça bloque la sortie de la 2.1.1, la 2.1.0 ayant un sacré tas de bug.

Committo,Ergo:Sum

[JLuc]

A propos de compilateur, est-ce qu'il y aurait une solution pour l'accés aux champs homonymes dans le cas d'une boucle avec jointure ?
cf par ex http://forum.spip.org/fr_224520.html

JLuc

[fil]

Pour les 2 premiers j'ai vu et c'est corrigé.

merci !

Pour le 3e, je peux envoyer une solution, mais il y aura intérêt à tester intensivement car on est dans la zone des cas pathologiques et ça risque de faire pire ailleurs. Pas sûr que ce soit une bonne idée de corriger qqch d'anormal de toutes façons.

L'usage d'une balise non prévue peut provenir de l'absence d'un
plugin. Maintenant c'est certain que la priorité est basse

-- Fil

[fil]

J'en profite pour rappeller que le message suivant:
http://article.gmane.org/gmane.comp.web.spip.devel/57708/
reste sans réponse depuis 10 jours, pour ne pas dire 15 puisque c'est toujours le même point en discussion.
C'est 3 fois rien mais ça bloque la sortie de la 2.1.1, la 2.1.0 ayant un sacré tas de bug.

Honnêtement je n'ai pas compris la question. Le statu quo ne me gêne
pas, mais si tu as mieux à proposer je ne vois pas ce qui te fait
hésiter. Sachant qu'il est de toutes façons toujours possible de
(re)définir exec=cfg indépendamment du plugin CFG.

-- Fil

[esj]

Tu n'étais pas le seul, et justement j'aimerais être sûr qu'à présent tout le monde a compris que pour le moment la seule nouveauté est l'abstraction de lien vers CFG permettant de fournir un autre lien. Et la seule question en suspens est de conserver la méthode d'abstraction convenue entre Cédric et moi (une entrée dans plugin.xml) ou de la remplacer par une fonction calculée (qui finalement aurait mes préférences).

Committo,Ergo:Sum

[cerdic]

hop, voilà, j'ai enfin eu le temps de me pencher dessus.
Moi ce que je voulais c'est qu'on puisse indiquer dans <config> directement le nom d'un exec (qui peut etre un php ou un squelette html sans php, rappelons le ...).
Avec un ou plusieurs formulaires de configuration dans cette page, cela permet d'avoir un raccourci vers la page de config, qui n'est plus forcèment un CFG.

J'ai bien noté que pour le moment, CVT seul ne permet pas encore de faire un formulaire de config sans PHP, mais c'est bien l'objectif a atteindre, par une extraction d'une version simplifiée minimale de CFG.
Cela permettra du coup d'écrire une page de config complète, et de la linker dans le panneau d'admin plugin sans ecrire de PHP.

J'ai conservé la possibilité que tu as introduit d'utiliser une fonction php qui génèrera le lien, ce qui pourrait permettre d'envoyer un formulaire de config ajax utilisable sur place, comme tu l'indiquais.
Néanmoins, je reste très sceptique sur l'ergonomie de ce mode de fonctionnement, car il me semble que la configuration d'une fonction doit se faire par les entrées pertinentes de la navigation, pas en sachant d'avance si c'est un plugin ou non.

Voila, donc si
http://trac.rezo.net/trac/spip/changeset/15721
ne casse rien chez toi, c'est aussi bon pour moi, et je le reporte en branche dev.

Cédric

[cerdic]

avec un exemple d'utilisation ici
http://zone.spip.org/trac/spip-zone/changeset/38479

[esj]

J'ai bien noté que pour le moment, CVT seul ne permet pas encore de faire un formulaire de config sans PHP, mais c'est bien l'objectif a atteindre, par une extraction d'une version simplifiée minimale de CFG.
Cela permettra du coup d'écrire une page de config complète, et de la linker dans le panneau d'admin plugin sans ecrire de PHP.

tout à fait.

J'ai conservé la possibilité que tu as introduit d'utiliser une fonction php qui génèrera le lien, ce qui pourrait permettre d'envoyer un formulaire de config ajax utilisable sur place, comme tu l'indiquais.

ok.

Néanmoins, je reste très sceptique sur l'ergonomie de ce mode de fonctionnement, car il me semble que la configuration d'une fonction doit se faire par les entrées pertinentes de la navigation, pas en sachant d'avance si c'est un plugin ou non.

je ne comprends pas ce que tu veux dire: à ce point du code il s'agit de configurer un plugin pas une fonction ! Par ailleurs je ne tiens particulièrement au mode de fonctionnement que j'ai évoqué, je veux juste qu'à l'occasion de la sortie d'une version qui ne fait que corriger des bugs on ne se ferme pas une porte qui se révèlerait utile voir indispensable à l'écriture d'un convertisseur des peudo-squelettes de CFG, ou autre boulot autour de ça.

Voila, donc si
http://trac.rezo.net/trac/spip/changeset/15721
ne casse rien chez toi, c'est aussi bon pour moi, et je le reporte en branche dev.

Ca ne me gene pas si ça casse un code ne marchant que sur une SVN, le pb n'est pas là. Ce qui me gêne c'est qu'il n'est fondamentalement pas bon de construire des specs où les objets peuvent avoir plusieurs significations (ici parfois un nom de fichier, parfois un nom de fonction): ça n'aide pas à la mémorisation de ce qu'on doit écrire dans plugin.xml et ça alourdit le code à l'exécution. De plus, ce que tu as écrit duplique ce qui est dans ecrire/index.php. Si on a besoin un jour de modifier ce déclenchement dans ce fichier, à tous les coups personne ne se souviendra qu'il faut modifier un clône dans un fichier nommé trompeusement afficher_plugin.php.

Je préfère donc la solution que je proposais: ne rien mettre dans plugin.xml et regarder si la fonction <plugin>_configure existe, censé ramener du HTML avec au moins une balise A vers le script de config du plugin, ajaxé ou non. On peut proposer en standard une fonction qui produit cette balise avec comme Href un generer_url_ecrire sur <plugin>_configure, c'est-à-dire en gros ce que tu as écrit, mais éviter à tout prix de mettre de l'ambiguité dans les specs et de la redondance dans le code.

Committo,Ergo:Sum

[cerdic]

J'ai bien noté que pour le moment, CVT seul ne permet pas encore de faire un formulaire de config sans PHP, mais c'est bien l'objectif a atteindre, par une extraction d'une version simplifiée minimale de CFG.
Cela permettra du coup d'écrire une page de config complète, et de la linker dans le panneau d'admin plugin sans ecrire de PHP.

tout à fait.

J'ai conservé la possibilité que tu as introduit d'utiliser une fonction php qui génèrera le lien, ce qui pourrait permettre d'envoyer un formulaire de config ajax utilisable sur place, comme tu l'indiquais.

ok.

Néanmoins, je reste très sceptique sur l'ergonomie de ce mode de fonctionnement, car il me semble que la configuration d'une fonction doit se faire par les entrées pertinentes de la navigation, pas en sachant d'avance si c'est un plugin ou non.

je ne comprends pas ce que tu veux dire: à ce point du code il s'agit de configurer un plugin pas une fonction ! Par ailleurs je ne tiens particulièrement au mode de fonctionnement que j'ai évoqué, je veux juste qu'à l'occasion de la sortie d'une version qui ne fait que corriger des bugs on ne se ferme pas une porte qui se révèlerait utile voir indispensable à l'écriture d'un convertisseur des peudo-squelettes de CFG, ou autre boulot autour de ça.

Voila, donc si
http://trac.rezo.net/trac/spip/changeset/15721
ne casse rien chez toi, c'est aussi bon pour moi, et je le reporte en branche dev.

Ca ne me gene pas si ça casse un code ne marchant que sur une SVN, le pb n'est pas là. Ce qui me gêne c'est qu'il n'est fondamentalement pas bon de construire des specs où les objets peuvent avoir plusieurs significations (ici parfois un nom de fichier, parfois un nom de fonction): ça n'aide pas à la mémorisation de ce qu'on doit écrire dans plugin.xml et ça alourdit le code à l'exécution.

Oui.

De plus, ce que tu as écrit duplique ce qui est dans ecrire/index.php. Si on a besoin un jour de modifier ce déclenchement dans ce fichier, à tous les coups personne ne se souviendra qu'il faut modifier un clône dans un fichier nommé trompeusement afficher_plugin.php.

c'est vrai, oui

Je préfère donc la solution que je proposais: ne rien mettre dans plugin.xml et regarder si la fonction <plugin>_configure existe, censé ramener du HTML avec au moins une balise A vers le script de config du plugin, ajaxé ou non. On peut proposer en standard une fonction qui produit cette balise avec comme Href un generer_url_ecrire sur <plugin>_configure, c'est-à-dire en gros ce que tu as écrit, mais éviter à tout prix de mettre de l'ambiguité dans les specs et de la redondance dans le code.

Mais tu force le passage par l'écriture d'une fonction PHP, le contraire de ce qu'on veut éviter. Le but est bien de permettre de faire un plugin avec configuration, sans écrire de PHP.

Je propose alors une synthèse de tous cela :
- si présent, <config>...</config> désigne uniquement un exec, ce qui evite tout besoin de détecter, et l'url de l'exec est utilisée pour le lien
- en son absence, on regarde si une fonction <plugin>_configure existe, et elle est utilisée dans ce cas pour générer le lien
- sinon, on s'en réfère à CFG si il est là.

Ainsi, aucune ambiguité de spec, et on a toutes les possibilités.
Ça te semble bien ?
Cédric

[esj]

Je préfère donc la solution que je proposais: ne rien mettre dans plugin.xml et regarder si la fonction <plugin>_configure existe, censé ramener du HTML avec au moins une balise A vers le script de config du plugin, ajaxé ou non. On peut proposer en standard une fonction qui produit cette balise avec comme Href un generer_url_ecrire sur <plugin>_configure, c'est-à-dire en gros ce que tu as écrit, mais éviter à tout prix de mettre de l'ambiguité dans les specs et de la redondance dans le code.

Mais tu force le passage par l'écriture d'une fonction PHP, le contraire de ce qu'on veut éviter. Le but est bien de permettre de faire un plugin avec configuration, sans écrire de PHP.

Si ce qu'on cherche dans exec c'est un script PHP d'un certain nom, c'est qu'on a déjà écrit du PHP !
Ta proposition n'atteint son but que si ce qu'on trouve est un squelette du nom indiqué,
car la vraie différence entre ta proposition et la mienne est que tu cherches 2 choses (un script PHP ou un squelette) et moi une (une fonction PHP),
les autres différences étant mineures.

Je propose alors une synthèse de tous cela :
- si présent, <config>...</config> désigne uniquement un exec, ce qui evite tout besoin de détecter, et l'url de l'exec est utilisée pour le lien
- en son absence, on regarde si une fonction <plugin>_configure existe, et elle est utilisée dans ce cas pour générer le lien
- sinon, on s'en réfère à CFG si il est là.

En somme tu répartis ton ambiguité entre les 2 métodes de spec: info dans plugin.xml ou fonction calculée dans le code.
Mais je ne vois plus où tu fais intervenir ton squelette à présent: ta proposition ne me semble plus prendre en compte le squelette config_gravatar que tu montrais dans:

Connexion · GitLab

Committo,Ergo:Sum

[cerdic]

Je préfère donc la solution que je proposais: ne rien mettre dans plugin.xml et regarder si la fonction <plugin>_configure existe, censé ramener du HTML avec au moins une balise A vers le script de config du plugin, ajaxé ou non. On peut proposer en standard une fonction qui produit cette balise avec comme Href un generer_url_ecrire sur <plugin>_configure, c'est-à-dire en gros ce que tu as écrit, mais éviter à tout prix de mettre de l'ambiguité dans les specs et de la redondance dans le code.

Mais tu force le passage par l'écriture d'une fonction PHP, le contraire de ce qu'on veut éviter. Le but est bien de permettre de faire un plugin avec configuration, sans écrire de PHP.

Si ce qu'on cherche dans exec c'est un script PHP d'un certain nom, c'est qu'on a déjà écrit du PHP !
Ta proposition n'atteint son but que si ce qu'on trouve est un squelette du nom indiqué,
car la vraie différence entre ta proposition et la mienne est que tu cherches 2 choses (un script PHP ou un squelette)

oui car on a deux façon d'écrire un exec : un script php ou un squelette html. La première est utile dans les cas complexes, et la deuxième est de plus en plus souvent utilisée, en particulier quand on ne veut pas coder de PHP

et moi une (une fonction PHP),
les autres différences étant mineures.

Je propose alors une synthèse de tous cela :
- si présent, <config>...</config> désigne uniquement un exec, ce qui evite tout besoin de détecter, et l'url de l'exec est utilisée pour le lien
- en son absence, on regarde si une fonction <plugin>_configure existe, et elle est utilisée dans ce cas pour générer le lien
- sinon, on s'en réfère à CFG si il est là.

En somme tu répartis ton ambiguité entre les 2 métodes de spec: info dans plugin.xml ou fonction calculée dans le code.
Mais je ne vois plus où tu fais intervenir ton squelette à présent: ta proposition ne me semble plus prendre en compte le squelette config_gravatar que tu montrais dans:
Connexion · GitLab

si, ça ne change rien
<config>config_gravatar</config>
generera un lien vers ?exec=config_gravatar
qui est implémenté par
prive/exec/config_gravatar.html

Cédric

[esj]

Ta proposition n'atteint son but que si ce qu'on trouve est un squelette du nom indiqué,
car la vraie différence entre ta proposition et la mienne est que tu cherches 2 choses (un script PHP ou un squelette)

oui car on a deux façon d'écrire un exec : un script php ou un squelette html.

Donc il y avait une double ambiguité dans ta proposition initiale, bonjour la clarté.

Repartons du point de départ. Ce qu'on veut c'est insérer dans la page admin_plugin
des bouts de HTML contenant chacun une balise A menant vers la config du plugin,
laquelle est le plus souvent une URL de exec/.
Alors je pense que le mieux est de dire que l'entrée "config" de plugin.xml
est nécessairement un squelette, et qu'en son absence admin_plugin
fera comme is le squelette serait:

  <div class='cfg_link'>
    <a href='#URL_ECRIRE{configurer_$nomplugin}'><img
    src="cfg-16.png" width="16" height="16" alt="Configurer"
    ></a>
  </div>"

ou rien du tout si exec/configure-$nomplugin.

A vous les studios.

Committo,Ergo:Sum

[esj]

si PAS de exec/... voulais-je dire

[cerdic]

Ta proposition n'atteint son but que si ce qu'on trouve est un squelette du nom indiqué,
car la vraie différence entre ta proposition et la mienne est que tu cherches 2 choses (un script PHP ou un squelette)

oui car on a deux façon d'écrire un exec : un script php ou un squelette html.

Donc il y avait une double ambiguité dans ta proposition initiale, bonjour la clarté.

Je ne vois pas l'ambiguité. Les pages de l'espace privé peuvent être écrites selon deux méthodes différentes, ça n'a rien de spécifique à la configuration d'un plugin.

Repartons du point de départ. Ce qu'on veut c'est insérer dans la page admin_plugin
des bouts de HTML contenant chacun une balise A menant vers la config du plugin,
laquelle est le plus souvent une URL de exec/.
Alors je pense que le mieux est de dire que l'entrée "config" de plugin.xml
est nécessairement un squelette,

tu veux dire que ce doit être le nom d'un squelette SPIP, qui sera évalué pour produire le html inséré à la place du bouton ?

et qu'en son absence admin_plugin
fera comme is le squelette serait:

  <div class='cfg_link'>
    <a href='#URL_ECRIRE{configurer_$nomplugin}'><img
    src="cfg-16.png" width="16" height="16" alt="Configurer"
    ></a>
  </div>"

ou rien du tout si exec/configure-$nomplugin.

On impose donc le nom de l'exec pour qu'il apparaisse en raccourci dans le panneau d'admin_plugin ;
et on oblige à nouveau à faire la double recherche du exec en php ou en html, avec, dans le second cas, la redondance de code que du dénonçais dans le mail précédent.
On peut toujours factoriser ce code là, cela dit.
Donc c'est gérable.

Disons que l'on privilégie le cas de <config> qui servira a faire un squelette de configuration en place, mais d'un autre côté cela permet de traiter potentiellement tous les cas sans nécessiter l'écriture de php

Cédric

[esj]

Je ne vois pas l'ambiguité. Les pages de l'espace privé peuvent être écrites selon deux méthodes différentes,

DEUX choses désignées par UN nom ça s'appelle une ambguïté.
Que ce soit une évidence pour ceux qui ont l'habitude, soit,
mais c'est typiquement ce qui fait fuir un nouvel arrivant quand il essaye de comprende le code,
et qui rend compliqué voire impossible toute automatisation.

tu veux dire que ce doit être le nom d'un squelette SPIP, qui sera évalué pour produire le html inséré à la place du bouton ?

oui, avec recuperer_fond

et qu'en son absence admin_plugin
fera comme is le squelette serait:

  <div class='cfg_link'>
    <a href='#URL_ECRIRE{configurer_$nomplugin}'><img
    src="cfg-16.png" width="16" height="16" alt="Configurer"
    ></a>
  </div>"

ou rien du tout si exec/configure-$nomplugin.

On impose donc le nom de l'exec

Attention je parle là du comportement par défaut, quand "config" n'est pas dans plugin.xml.
Pour ce cas, ta dernière proposition était de chercher la fonction <plugin>_configure
c'est une contrainte équivalente.

et on oblige à nouveau à faire la double recherche du exec en php ou en html,
avec, dans le second cas, la redondance de code que du dénonçais dans le mail précédent.

Je répète que ce n'est que dans le cas par défaut, c'est déjà ça de gagné.
Le problème derrière le reste à mon avis est plutôt au niveau de la balise #URL_ECRIRE:
elle produit systématiquement l'URL même si le script n'existe pas, ce qui ne me semble pas heureux.
Ce serait sympa de pouvoir faire
[...<a href="(#URL_ECRIRE{X})">clic</a>...]
du coup on ne verrait rien s'il n'y pas de script de config.

On peut toujours factoriser ce code là, cela dit.

Oui, et URL_ECRIRE s'en servirait.

Donc c'est gérable.

Disons que l'on privilégie le cas de <config> qui servira a faire un squelette de configuration en place,

je trouve normal de privilégier ceux qui se donnent la peine de donner une spec complète.

mais d'un autre côté cela permet de traiter potentiellement tous les cas sans nécessiter l'écriture de php

Yep. Bon alors ça y est on est d'accord ?

Committo,Ergo:Sum

[cerdic]

Je ne vois pas l'ambiguité. Les pages de l'espace privé peuvent être écrites selon deux méthodes différentes,

DEUX choses désignées par UN nom ça s'appelle une ambguïté.
Que ce soit une évidence pour ceux qui ont l'habitude, soit,
mais c'est typiquement ce qui fait fuir un nouvel arrivant quand il essaye de comprende le code,
et qui rend compliqué voire impossible toute automatisation.

tu veux dire que ce doit être le nom d'un squelette SPIP, qui sera évalué pour produire le html inséré à la place du bouton ?

oui, avec recuperer_fond

et qu'en son absence admin_plugin
fera comme is le squelette serait:

  <div class='cfg_link'>
    <a href='#URL_ECRIRE{configurer_$nomplugin}'><img
    src="cfg-16.png" width="16" height="16" alt="Configurer"
    ></a>
  </div>"

ou rien du tout si exec/configure-$nomplugin.

On impose donc le nom de l'exec

Attention je parle là du comportement par défaut, quand "config" n'est pas dans plugin.xml.

oui, mais en pratique ça va être le cas majoritaire.
On va pas s'amuser à écrire un squelette à chaque fois pour juste y mettre un lien.

Pour ce cas, ta dernière proposition était de chercher la fonction <plugin>_configure
c'est une contrainte équivalente.

oui, mais il m'avait semblé comprendre que tu préférais presque cela pour ton scenario.

et on oblige à nouveau à faire la double recherche du exec en php ou en html,
avec, dans le second cas, la redondance de code que du dénonçais dans le mail précédent.

Je répète que ce n'est que dans le cas par défaut, c'est déjà ça de gagné.
Le problème derrière le reste à mon avis est plutôt au niveau de la balise #URL_ECRIRE:
elle produit systématiquement l'URL même si le script n'existe pas, ce qui ne me semble pas heureux.
Ce serait sympa de pouvoir faire
[...<a href="(#URL_ECRIRE{X})">clic</a>...]
du coup on ne verrait rien s'il n'y pas de script de config.

ben je pensais pas écrire vraiment un squelette pour le cas par défaut.
Et dans le cas "pas par défaut", le developpeur du plugin sait bien si il a un exec ou pas, quand il écrit son squelette.

On peut toujours factoriser ce code là, cela dit.

Oui, et URL_ECRIRE s'en servirait.

Donc c'est gérable.

Disons que l'on privilégie le cas de <config> qui servira a faire un squelette de configuration en place,

je trouve normal de privilégier ceux qui se donnent la peine de donner une spec complète.

mais d'un autre côté cela permet de traiter potentiellement tous les cas sans nécessiter l'écriture de php

Yep. Bon alors ça y est on est d'accord ?

J'ai l'impression qu'on a un compromis, oui.

Cédric

[esj]

Ce serait sympa de pouvoir faire

[...<a href="(#URL_ECRIRE{X})">clic</a>...]
du coup on ne verrait rien s'il n'y pas de script de config.

ben je pensais pas écrire vraiment un squelette pour le cas par défaut.

C'est pourtant dans la logique de la "squelettisation de l'espace privé".

J'ai l'impression qu'on a un compromis, oui.

A la bonne heure, je m'en occupe.

Committo,Ergo:Sum