[spip-dev] [SPIP Zone] [Spip-zone-commit] r40425 - _plugins_/ortho

[esj]

Est-ce qu'on peut discuter sans caricaturer ? Je trouve quand même fou cette méthode de travail qui consiste à ne rien dire d'une spécification ouverte à la discussion depuis un bon moment (une première version de l'article date du 17 aout), et d'attendre un commit qui ne casse RIEN mais ouvre une possibilité de résolution d'un problème reconnu comme tel par tous pour enfin faire état d'une difficulté technique oubliée par tous sauf soi. Et en plus au lieu de discuter des pbs de fond, on s'empaille sur une poignée de lignes de code dont je dis pour la millième fois que c'est du transitoire. L'art et la manière de gaspiller l'énergie de tout le monde.

Alors essayons de discuter calmement. Actuellement 50% des fichiers plugin.xml ne sont PAS du XML, je trouve déjà contre-productif qu'on laisse entendre qu'on ne sait même pas ce que c'est que XML, et que SPIP ne râle pas à leur sujet, ce qui fait que des plugins sont mal mis en oeuvre sans rien dire, voir carrément font planter SPIP sans qu'on sache quel fichier en est responsable. L'intérêt d'une DTD est de garantir qu'un fichier mal écrit sera dénoncé proprement, c'est une première raison de cesser de bricoler à leur sujet.

La fonction plugin_propre a effectivement toujours eu pour rôle de traiter dérogatoirement des infos issues de plugin.xml.
La difficulté technique que plusieurs plugins auraient le même préfixe me paraît simplement renforcer l'idée que cette situation n'est pas souhaitable. Mais de toutes façons on dispose aussi du nom du répertoire du plugin qui lève l'ambiguité, il ne faut pas se noyer dans des verres d'eau. De plus, a priori les différentes versions d'un même plugin vont avoir la même description, même avec la solution actuelle du préfixe on s'arrêterait sur le premier fichier ce n'est pas un drame.

Enfin pour Quentin, je trouve contradictoire de dire que tu vas "lire le code" (et y trouver les fichiers significatifs n'a rien d'évident) mais que tu ne veux pas lire une chaîne de langue bien précise d'un ficher de langue bien précis. Que tu "n'utilise pas Contrib ou autre pour chercher des plugins" est justement la raison pour laquelle Eric et moi avons mis en route ce chantier: il faut plus contraindre les infos fournies par plugin.xml pour que ces sites de présentations donnent des informations complètes et claires, et dans toutes les langues disponibles.

Par ailleurs il faudrait arrêter de poster dans tous les sens: cette discussion impacte le noyau et donc à sa place sur spip-dev, et seulement secondairement sur les autres listes.

Committo,Ergo:Sum

[fil]

Je trouve quand même fou cette méthode de travail qui consiste à ne rien dire d'une
spécification ouverte à la discussion depuis un bon moment (une première version de
l'article date du 17 aout)

Si tu estimes qu'il faut lire, comprendre et assimiler tes écrits, et
en déduire toutes les
conséquences en moins de 12 jours, je ne sais pas qui est le plus fou

Perso, j'étais dès le départ contre le fait d'utiliser xml comme
format, car c'est trop
contraignant, en plus d'être moche. On va finir par mettre des CDATA
dedans, comme
ça ce sera "valide"... (et encore plus moche).

a priori les différentes versions d'un même plugin vont avoir la même description

là tu cherches VRAIMENT les difficultés, je me marre comme une baleine
rien qu'à imaginer que tu puisses imaginer un truc aussi génial qu'un
plugin qu'on décrirait dans l'interface avec la description d'un
autre.

Je vote revert !

-- Fil

[esj]

Je trouve quand même fou cette méthode de travail qui consiste à ne rien dire d'une
spécification ouverte à la discussion depuis un bon moment (une première version de
l'article date du 17 aout)

Si tu estimes qu'il faut lire, comprendre et assimiler tes écrits, et
en déduire toutes les
conséquences en moins de 12 jours, je ne sais pas qui est le plus fou

Ce ne sont pas "mes écrits" mais ceux d'Eric et moi sans parler des intervenants des discussions qu'il y eu autour auparavant.
Ce n'est pas plus fou de comprendre une DTD que de comprendre un commit en PHP.

Perso, j'étais dès le départ contre le fait d'utiliser xml comme
format, car c'est trop
contraignant, en plus d'être moche. On va finir par mettre des CDATA
dedans, comme
ça ce sera "valide"... (et encore plus moche).

Perso je n'étais pas pour non plus, mais ce que je trouve contre-productif ce sont les demi-mesures:
donner l'extension .xml à un fichier qui n'en est pas.
Maintenant, si tu as une autre proposition aussi précise qu'une DTD, montre la.

a priori les différentes versions d'un même plugin vont avoir la même description

là tu cherches VRAIMENT les difficultés, je me marre comme une baleine
rien qu'à imaginer que tu puisses imaginer un truc aussi génial qu'un
plugin qu'on décrirait dans l'interface avec la description d'un
autre.

Encore une fausse discussion: j'ai bien dit dans mon mail que ces plugins ayant même préfixe étaient une aberration, que si on y tenait vraiment on pouvait s'en sortir avec le nom du répertoire, et j'ai seulement signalé qu'au pire on allait tomber sur ce truc là qui n'était pas dramatique. Pourquoi ne parles-tu que de ce que j'ai bien dit être une roue de secours que je désapprouve à la base ?

Enfin, tant mieux si ça te fait rire.

Committo,Ergo:Sum

[cerdic]

Cassons tout, donc.

Est-ce qu'on peut discuter sans caricaturer ? Je trouve quand même fou cette méthode de travail qui consiste à ne rien dire d'une spécification ouverte à la discussion depuis un bon moment (une première version de l'article date du 17 aout),

Ah mais excuse moi, mais je donne mon avis. Il ne faut cependant pas s'attendre à ce qu'on réagisse tous les jours à une discussion qui se tient dans un nouveau lieu en dehors de tous les circuits habituels de discussion (à commencer par la liste spip-dev).
Donc oui, c'est en lisant le commit que je suis allé prendre connaissance de la dernière version des tables de la loi et que je réagis.

et d'attendre un commit qui ne casse RIEN mais ouvre une possibilité de résolution d'un problème reconnu comme tel par tous pour enfin faire état d'une difficulté technique oubliée par tous sauf soi.

As-tu seulement posé une fois la question "Pourquoi on utilise pas un fichier de langue ?"
Auquel cas j'aurais pu te faire la réponse technique argumentée.

Mais comme tu semble avoir convenu qu'il fallait faire comme ça j'en ai déduis que tu avais résolu la difficulté technique sous-jacente.

Et en plus au lieu de discuter des pbs de fond, on s'empaille sur une poignée de lignes de code dont je dis pour la millième fois que c'est du transitoire. L'art et la manière de gaspiller l'énergie de tout le monde.

Alors essayons de discuter calmement. Actuellement 50% des fichiers plugin.xml ne sont PAS du XML

oui en effet.
On a relaché les contraintes sur les é car cela fait suer tout le monde de trouver le é correspondant, et on a autorisé le html dans les balises pour éviter les horribles CDATA.
C'est du XML adapté à la réalité du terrain, dirons nous.

A titre d'information Toggg avait mis en place une DTD déja pour traiter les plugin.xml dans l'empaqueteur, avec le résultat qu'il cassait en permanence et que l'on passait notre temps (enfin surtout Arnaud ventre) à aller corriger les entités et autres balises html interdites.

, je trouve déjà contre-productif qu'on laisse entendre qu'on ne sait même pas ce que c'est que XML, et que SPIP ne râle pas à leur sujet,

Appelons ça plugin.pasxml si on préfère.
Mais quitte à changer de formalisme, j'avoue que je préfèrerai passer en yaml, plus lisible par les humains.

ce qui fait que des plugins sont mal mis en oeuvre sans rien dire, voir carrément font planter SPIP sans qu'on sache quel fichier en est responsable. L'intérêt d'une DTD est de garantir qu'un fichier mal écrit sera dénoncé proprement, c'est une première raison de cesser de bricoler à leur sujet.

La fonction plugin_propre a effectivement toujours eu pour rôle de traiter dérogatoirement des infos issues de plugin.xml.
La difficulté technique que plusieurs plugins auraient le même préfixe me paraît simplement renforcer l'idée que cette situation n'est pas souhaitable.

Ben il s'agit très simplement des différentes versions d'un même plugin ...
Ou de deux plugins différents qui rendent le même service et sont donc interchangeables.
Il y a plein de bonnes raisons pour cela.

Mais de toutes façons on dispose aussi du nom du répertoire du plugin qui lève l'ambiguité, il ne faut pas se noyer dans des verres d'eau. De plus, a priori les différentes versions d'un même plugin vont avoir la même description,

Heu ben non, justement. Surtout que tu expliques dans http://spip21.smellup.net/spip.php?article7 que finalement cette description devrait "donner une description plus détaillée, notamment les nouveautés lors d’un changement de version"

même avec la solution actuelle du préfixe on s'arrêterait sur le premier fichier ce n'est pas un drame.

mais un bug, à coup sur.

Enfin pour Quentin, je trouve contradictoire de dire que tu vas "lire le code" (et y trouver les fichiers significatifs n'a rien d'évident) mais que tu ne veux pas lire une chaîne de langue bien précise d'un ficher de langue bien précis. Que tu "n'utilise pas Contrib ou autre pour chercher des plugins" est justement la raison pour laquelle Eric et moi avons mis en route ce chantier: il faut plus contraindre les infos fournies par plugin.xml pour que ces sites de présentations donnent des informations complètes et claires, et dans toutes les langues disponibles.

Quentin a raison sur le fait que plugin.xml doit se suffire à lui même pour fournir les informations de crédits, licence, auteur du plugin, pour que celles-ci soient lisibles par tout un chacun, y compris n'importe qui ne connaissant pas SPIP et qui veut reprendre du code existant.

Cédric

[esj]

Ah mais excuse moi, mais je donne mon avis. Il ne faut cependant pas s'attendre à ce qu'on réagisse tous les jours à une discussion qui se tient dans un nouveau lieu en dehors de tous les circuits habituels de discussion (à commencer par la liste spip-dev).

Cet article a été annoncé sur spip-dev et spip-zone, il n'y avait pas injonction à poster sur son forum, c'était ouvert. Pas de mauvais procès.

As-tu seulement posé une fois la question "Pourquoi on utilise pas un fichier de langue ?"

...

Mais comme tu semble avoir convenu qu'il fallait faire comme ça j'en ai déduis que tu avais résolu la difficulté technique sous-jacente.

Je te remercie de la confiance que tu me fais, mais si Eric et moi avons choisi de rédiger soigneusement une spec avant de faire des commit, c'est justement qu'on ne s'estimait pas omniscients et qu'on soumettait ça à la critique. Ca s'appelle le travail collaboratif.

Actuellement 50% des fichiers plugin.xml ne sont PAS du XML

oui en effet.
On a relaché les contraintes sur les é car cela fait suer tout le monde de trouver le é correspondant,

Ca, ça ce résoud facilement: les entités HTML décrivant les lettres accentuées sont dans des DTD officielles séparées que notre DTD peut inclure au besoin, ça marche tout seul j'ai testé.

et on a autorisé le html dans les balises pour éviter les horribles CDATA.

XML est un formalisme qui est très facilement horrible à l'usage, en particulier dès qu'on est contraint au CDATA,
j'ai été le premier à le dire à l'époque où tu l'as choisi pour ces fichiers. Mais il répond à un besoin, et parfois plutôt bien si on réfléchit le temps qu'il faut à la DTD. Je ne fais pas de purisme à son sujet, mais, comme le dit l'article, l'invalidité des balises HTML ne fait que dénoncer ce qu'on savait, savoir que ces textes à cet endroit ne sont pas une solution satisfaisante.

Mais quitte à changer de formalisme, j'avoue que je préfèrerai passer en yaml, plus lisible par les humains.

L'avantage d'une DTD est qu'un validateur va assurer que le fichier est bien écrit. Faute de l'utiliser tu as dû faire un développement avec spip_xml_load qui analyse ce pseudo-XML, et qui n'est pas fiable. Je ne vois vraiment pas l'intérêt de repartir sur un autre développement, d'autant que toute cette discussion est partie non pas des mérites comparés de XML et Yaml ou autre, mais de comment faire pour gérer traduction et mise en pages des textes de description des plugins. C'est ce problème qu'il faut résoudre, le reste suivra, et a priori sans plus de problème dans un formalise que dans un autre.

Ben il s'agit très simplement des différentes versions d'un même plugin ...
Ou de deux plugins différents qui rendent le même service et sont donc interchangeables.
Il y a plein de bonnes raisons pour cela.

Il me semble quand même que le code de SPIP fait souvent l'hypohèse que le préfixe est unique, et donc que cette situation est dérogatoire et doit déboucher sur des contradictions (cache mal vidé et autres). On est en plein dans la situation où on va renoncer à une bonne solution générale à cause de cas particuliers contestables.

Quentin a raison sur le fait que plugin.xml doit se suffire à lui même pour fournir les informations de crédits, licence, auteur du plugin, pour que celles-ci soient lisibles par tout un chacun, y compris n'importe qui ne connaissant pas SPIP et qui veut reprendre du code existant.

Tout le boulot avec Eric est fait dans l'optique de fournir des pages Web permettant de trouver facilement le plugin qui fait ce qu'on veut. Si on part du principe que de toutes façons rien ne vaut le fichier brut, alors fermons plugins.spip.net et files.spip.org, abandonnons SVP et STEP, et annonçons sur spipnet que pour trouver le plugin qu'il vous faut, il faut aller lire tous les fichiers plugin.xml de Trac. Comme tu vois, moi aussi je sais faire dans la caricature.

Committo,Ergo:Sum

[cerdic]

Oui bien sûr. Le prefixe est unique pour les plugins *activés*, dont les fichiers de langue sont chargés etc. Et il est normal de ne pas pouvoir activer deux versions d'un même plugin.

Mais le descriptif doit bien pouvoir être affiché pour n'importe quel plugin, donc y compris tous les plugins *non activés* sur lesquels l'unicité du prefixe n'a pas de sens.
Autrement dit, j'ai le droit d'avoir dans mon dossier plugins/ N versions du même plugin dont je n'activerai qu'une seule version. Et c'est bien pour tous ces plugins non activés que la question se pose et pour lequel on ne sait pas charger le fichier de langue dans l'état actuel des choses.

J'ai noté que ce même problème se pose pour SVP, et que tu l'as évacué indirectement en supposant que l'empaqueteur allait recopier le contenu des chaines de langue dans le fichier XML.

Cédric

[esj]

Mais le descriptif doit bien pouvoir être affiché pour n'importe quel plugin, donc y compris tous les plugins *non activés* sur lesquels l'unicité du prefixe n'a pas de sens.
Autrement dit, j'ai le droit d'avoir dans mon dossier plugins/ N versions du même plugin dont je n'activerai qu'une seule version. Et c'est bien pour tous ces plugins non activés que la question se pose et pour lequel on ne sait pas charger le fichier de langue dans l'état actuel des choses.

Ici il faudrait donc se baser sur le répertoire du plugin considéré pour adresser directement le fichier de langue.
Ce n'est pas infaisable, mais dans inc/traduire il y a une interprétation bizarre des / dans un module de langue:

  // modules demandes explicitement <xxx/yyy/zzz:code>
  if (strpos($ori,':')) {
    list($modules,$code) = explode(':',$ori,2);
    $modules = explode('/', $modules);

Ca remonte à il y a 7 ans:
http://trac.rezo.net/trac/spip/changeset/2196/spip/ecrire/inc_lang.php3

A quoi ça sert ? Est-ce documenté ? Est-ce encore utilisé ? Ca interdit de donner un path pour un module, c'est dommage.

J'ai noté que ce même problème se pose pour SVP, et que tu l'as évacué indirectement en supposant que l'empaqueteur allait recopier le contenu des chaines de langue dans le fichier XML.

Nous l'avons évacué effectivement avec l'idée qu'elles se retrouvent, avec l'avantage d'évacuer la balise multi que sinon les traducteurs auraient à gérer. A noter que si ces chaînes de langues contiennent des balistes HTML, le fichier archives.xml ne sera pas valide mais on s'en fout car c'est un fichier dérivé qu'on n'a pas besoin de re-contrôler: nous ne sommes donc pas aussi puristes qu'il peut sembler.

Committo,Ergo:Sum

[fil]

Maintenant, si tu as une autre proposition aussi précise qu'une DTD, montre la.

Halte aux arguments d'autorité.

Je suis tout à fait pour le fait que vous passiez par une
formalisation complète et précise, et je ne réagis qu'à certains
inconvénients de la proposition en question au moment où je m'en rends
compte.

C'est déjà pas mal comme contribution. Je pourrais aussi bien, si tu
préfères, m'en foutre et coder autour quand je rencontrerai de
nouveaux problèmes.

Ah oui, j'ai consacré ma soirée d'hier à faire aveuglément ce que tu
avais demandé dans trad-lang pour mettre au carré le plugin "ortho" ;
on peut penser que je ne suis pas doué, mais bon j'ai galéré avec la
base et c'est au terme de ces deux heures de travail que j'ai fini par
réaliser ce que tu voulais faire... et que ça ne marchait pas... la
prochaine fois, je m'abstiens ?

-- Fil

[fil]

   // modules demandes explicitement <xxx/yyy/zzz:code>
   if \(strpos\($ori,':'\)\) \{
           list\($modules,$code\) = explode\(':',$ori,2\);
           $modules = explode\('/', $modules\);

Ca remonte à il y a 7 ans:
http://trac.rezo.net/trac/spip/changeset/2196/spip/ecrire/inc_lang.php3

A quoi ça sert ? Est-ce documenté ? Est-ce encore utilisé ? Ca interdit de donner un path pour un module, c'est dommage.

ça sert à pouvoir dire "je veux la chaine code que l'on va trouver
dans les modules xxx, yyy ou zzz". Je ne sais pas si c'est utilisé.

-- Fil

[eric_tonton (Eric Lupinacci)]

Donc, pour rester positif je fais quand même la modif d’ortho ce soir pour qu’il utilise ses propres fichiers de langue puisqu’ils existent ce qui permettra au moins de virer ces items de SPIP et on voit après ?

Eric

[fil]

Donc, pour rester positif je fais quand même la modif d'ortho ce soir pour
qu'il utilise ses propres fichiers de langue puisqu'ils existent ce qui
permettra au moins de virer ces items de SPIP

en fait ils sont déjà virés, donc oui il faudrait modifier ortho pour
qu'il appelle _T('ortho:ortho_xxx') à la place de _T('ortho_xxx')

il ne restera que la question du descriptif du plugin

et on voit après ?

voyons

-- Fil

[esj]

Bon ça semble n'avoir été utilisé que, coïncidence, pour le dérogatoire plugin ortho, et évacué lors des chgts d'hier.

Je pense avoir trouvé une solution au pb découvert ce matin. La version 2.1.1 étant insatisfaisante en l'état,
j'envoie cette solution sur cette branche, mais on pourra revenir à l'état d'hier si ça ne fait pas consensus.

Committo,Ergo:Sum

[azerttyu]

Bonjour

La difficulté technique que plusieurs plugins auraient le même préfixe me paraît simplement renforcer l'idée que cette situation n'est pas souhaitable.

Ben il s'agit très simplement des différentes versions d'un même plugin ...
Ou de deux plugins différents qui rendent le même service et sont donc interchangeables.
Il y a plein de bonnes raisons pour cela.

Autrement pourquoi pas renommer spip en drupal/joomla/autre cms/ ça
fournit à la base le même service, ridicule non ?

Ce genre de problématique est déjà résolu par tout les systèmes de
paquets (Provide de Debian Policy par exemple). Il serait bon de
prendre exemple sur eux pour en profiter le maximum. Ces derniers
temps, on démontre clairement les limitations du
formalisme/fonctionnement de plugin.xml

Km

[cerdic]

Ah ben GOGOGO
Y a deja emmanuel et eric sur le coup, n'hesite pas à compléter l'équipe.

Cédric

[eric_tonton (Eric Lupinacci)]

Emmanuel,

Ton dernier commit sur SPIP 2.1 provoque une regression dans les pages d’admin des plugins:

1. L’icone disparait car l’url n’est plus bonne
   ==> Pour corriger ce problème il suffit de remplacer la ligne 101 de plugins/afficher_plugin.php par

$i = inserer_attribut(image_reduire("$dir_plugins$plug_file/$i", 32),‹ alt ›,’’);

2. Les infos techniques version (si SVN) et répertoire ne sont plus correctes aussi parce que l’on pointe vers le mauvais répertoire à savoir dir_plugin/lang/prefix au lieu de dir_plugin. Le problème c’est que je ne trouve pas d’où ça vient…

Par contre, en regardant le code j’ai une autre remarque sur le fait de choisir d’autorité le module dir_plugin/lang/prefix. Il faut donc préciser que les items de ce type sont toujours dans le module de nom = au préfixe et pas un autre dérivé comme cela est possible du style : prefix_prive ou prefix_public.

[esj]

Emmanuel,

Ton dernier commit sur SPIP 2.1 provoque une regression dans les pages d'admin des plugins:

1) L'icone disparait car l'url n'est plus bonne
==> Pour corriger ce problème il suffit de remplacer la ligne 101 de plugins/afficher_plugin.php par
  $i = inserer_attribut(image_reduire("$dir_plugins$plug_file/$i", 32),'alt','');

ok oui.

2) Les infos techniques version (si SVN) et répertoire ne sont plus correctes aussi parce que l'on pointe vers le mauvais répertoire à savoir dir_plugin/lang/prefix au lieu de dir_plugin. Le problème c'est que je ne trouve pas d'où ça vient....

Je ne vois pas de quoi tu parles. Dans la page admin_plugin les quelques plugins que je regarde me semblent corrects.
Peux-tu préciser ?

Par contre, en regardant le code j'ai une autre remarque sur le fait de choisir d'autorité le module dir_plugin/lang/prefix. Il faut donc préciser que les items de ce type sont toujours dans le module de nom = au préfixe et pas un autre dérivé comme cela est possible du style : prefix_prive ou prefix_public.

Oui c'est vrai, mais Cédric a fait remarquer que si on a beaucoup de plugins activables ça fait beaucoup de fichier de langues à ouvrir, donc être particulièrement directif là-dessus est une nécessité qui ne pose pas de pb par ailleurs.

Committo,Ergo:Sum

[eric_tonton (Eric Lupinacci)]

Yep,

[esj]

Ben sur 2 machines où je regarde je n'ai pas ça, donc je ne sais pas où chercher.

Committo,Ergo:Sum

[esj]

Ah j'ai compris: en fait les 2 fautes proviennent du même bug et je testais avec ma correction.
Donc http://trac.rezo.net/trac/spip/changeset/16001 résoud les 2.

Committo,Ergo:Sum

[davux]

30/08/10, cedric.morin@yterium.com:

Oui bien sûr. Le prefixe est unique pour les plugins *activés*, dont
les fichiers de langue sont chargés etc. Et il est normal de ne pas
pouvoir activer deux versions d'un même plugin.

D'ailleurs, même si l'idée est intellectuellement séduisante, est-on
obligés de déployer les mécanismes de SPIP ? En abordant la
problématique sous l'angle XML, on pourrait avoir quelque chose du
genre :

<...>
    <description lang="fr">Blabla en français</description>
    <description lang="en">My taylor is rich</description>
    ...
</...>

Peut-être que l'idée a déjà été évoquée puis rejetée, mais je n'en
retrouve pas la trace.

[Je voulais répondre y'a un moment, mais j'avais un souci de connexion,
désolé du lag ^^]