[spip-dev] en finir avec les erreurs dues aux tirets dans les noms de boucle

Dev
1

Coucou,

j'ai modifié inc-calcul-squel de manière à ce que l'analyseur de boucles ne
plante plus sur les boucles marquées <BOUCLE-toto> au lieu de <BOUCLE_toto>.
Ca devrait supprimer nombre d'erreurs du type :

    function () missing...

ou
    boucle MACHIN manque tag fermant...

Mais attention, ça ne vaut pas absolution : si vous faites une boucle
nommée boucle_toto et une autre boucle-toto, ça va planter. Ca n'est pas
encore capable de traiter chaque boucle de manière indépendante, ni de gérer
ce qui suit :

<BOUCLE_x(ARTICLES){id_rubrique}>
#TITRE<br>
</BOUCLE_x>
<BOUCLE_x(BREVES){id_rubrique}>
#TITRE<br>
</BOUCLE_x>

Il n'y a pas des masses de modifs à faire dans le code, cela dit, pour y
arriver. Simplement la difficulté est de savoir comment gérer

<BOUCLE_x(ARTICLES){id_rubrique}>
#TITRE<br>
</BOUCLE_x>
<BOUCLE_x(BREVES){id_rubrique}>
#TITRE<br>
</BOUCLE_x>
<//BOUCLE_x>

Le dernier élément, là, il est conditionnel sur la première ou sur la
seconde boucle ? (En toute logique il doit l'être sur la seconde, ce qui
oblige à tenter de repérer le début de la seconde lorsqu'on est dans la
première... vous me suivez ?)

-- Fil

2

Salut,

j'ai modifié inc-calcul-squel de manière à ce que l'analyseur de boucles ne
plante plus sur les boucles marquées <BOUCLE-toto> au lieu de <BOUCLE_toto>.

Ce n'est pas à cet endroit que ça posait problème (BOUCLE-toto n'est pas
autorisé, normalement), mais entre <BOUCLE_to-to> et <BOUCLE_to_to>.

Mais attention, ça ne vaut pas absolution : si vous faites une boucle
nommée boucle_toto et une autre boucle-toto, ça va planter.

Il vaut mieux interdire les tirets, non ? On n'a pas le droit de faire
des boucles portant un nom identique, de toute façon.

a+

Antoine.

3

Hello,

j'ai modifié inc-calcul-squel de manière à ce que l'analyseur de
boucles ne plante plus sur les boucles marquées <BOUCLE-toto> au
lieu de <BOUCLE_toto>.

A mon avis, c'était nécessaire, puisque les boucles sont censées
commencer par '<BOUCLE' et non '<BOUCLE_'.

Par contre, autoriser dans le futur des noms de boucles identiques
pour des types différents, est à mon avis une mauvaise idée.

A mon avis, cela conduirait à plus de problèmes encore ...

Nicolas.

4

Ce n'est pas à cet endroit que ça posait problème (BOUCLE-toto n'est pas
autorisé, normalement), mais entre <BOUCLE_to-to> et <BOUCLE_to_to>.

Pas autorisé, c'est vrai dans le code, mais je ne vois pas l'intérêt de
cette limitation.

Il vaut mieux interdire les tirets, non ? On n'a pas le droit de faire
des boucles portant un nom identique, de toute façon.

J'ai l'impression de passer mon temps à donner cette réponse aux gens qui
ont des messages d'erreur incompréhensibles sur leurs pages (cf. les deux
types d'erreur mentionnées). L'autre solution est d'expliciter les messages
d'erreur, mais comme elles peuvent venir d'ailleurs, hum ! En général, il
vaut mieux être un peu plus souples dans la forme qu'on accepte, non ?

On n'a pas le droit de faire des boucles portant un nom identique, de
toute façon.

Ca, il va bien falloir que ça change ! Sinon on galère quand on fait sa
maquette avec des copier/coller d'exemples et de bouts de code !

@ Nicolas Hoizey <nhoizey@phpheaven.net> :

Par contre, autoriser dans le futur des noms de boucles identiques
pour des types différents, est à mon avis une mauvaise idée.

Mon exemple n'était pas terrible. Je ne parlais pas spécifiquement de types
différents, je voulais juste dire que les boucles devraient être
copi-collables sans qu'on ait à les renommer.

J'ai essayé d'ajouter un simple compteur de boucles, qui s'additionne
automagiquement au nom de la boucle, et ça marche très bien. Et il suffit,
avant de chercher </B$id_boucle> et <//B$id_boucle> de prendre la précaution
de ne pas dépasser un éventuel <B$id_boucle> ou <BOUCLE$id_boucle> qui
traînerait, pour juxtaposer des boucles ayant le même nom sans risquer de
mélanger les parties optionnelles.

Mais d'une part le compteur fait que les messages d'erreur, quand il y en a,
sont encore plus incompréhensibles (puisque le message dit par exemple
BOUCLE x_2 pas fermée, alors qu'on a que des boucles x).

D'autre part et surtout, cela doit être compatible avec les includes, donc
je suppose qu'on va plutôt ajouter un ou deux éléments dans la structure
class Boucle {
    var $type = 'boucle';
    var $id_boucle, $id_parent;
...

élements qui seraient a priori : nom du squelette, numéro de la boucle dans
le squelette. Et là c'est un peu trop pour moi je pense...

-- Fil

5

J'ai essayé d'ajouter un simple compteur de boucles, qui
s'additionne automagiquement au nom de la boucle, et ça marche très
bien. Et il suffit, avant de chercher </B$id_boucle> et
<//B$id_boucle> de prendre la précaution de ne pas dépasser un
éventuel <B$id_boucle> ou <BOUCLE$id_boucle> qui traînerait, pour
juxtaposer des boucles ayant le même nom sans risquer de mélanger
les parties optionnelles.

Avec ton système, plus besoin de nommer les boucles. Dangereux, non ?

Pour le reste, il est clair que l'inclusion de sous-squelettes est
attendu par plusieurs personnes comme un besoin important, et qu'il
faudra y venir, donc peut-être est-ce le moment ...

Nicolas.

6

@ Nicolas Hoizey <nhoizey@phpheaven.net> :

Avec ton système, plus besoin de nommer les boucles. Dangereux, non ?

Tu sais qu'en php tu peux écrire ton code comme ça :

    $var1 = 10;
    $var10 = "bonjour";
    $var3 = $var1.$var10;

incompréhensible, certes, impossible à débugguer, itou, mais "dangereux" ?
Le manuel et les exemples de spip indiquent la "bonne pratique", et ensuite
spip se débrouille, je ne vois pas le danger.

-- Fil

7

Avec ton système, plus besoin de nommer les boucles. Dangereux,
non ?

Tu sais qu'en php tu peux écrire ton code comme ça :
    $var1 = 10;
    $var10 = "bonjour";
    $var3 = $var1.$var10;

Oui, oui, je sais bien ... :wink:

incompréhensible, certes, impossible à débugguer, itou, mais
"dangereux" ?

Dangereux pour les nerfs du développeur parfois.

Le manuel et les exemples de spip indiquent la "bonne pratique", et
ensuite spip se débrouille, je ne vois pas le danger.

Là c'est plus grave, ce n'est pas l'utilisateur de SPIP qui va péter
un cable, ce sont les inscrits aux mailing-lists qui vont voir passer
la même question tous les jours ...

Nicolas.

8

Coucou,

L'autre solution est d'expliciter les
messages
d'erreur,

Oui, c'est cela qu'il faut faire à mon avis : un message "caractère non
autorisé dans le nom de la boucle", ou équivalent.

En général,
il
vaut mieux être un peu plus souples dans la forme qu'on accepte, non ?

Non, car après on est obligé d'y coller et ça peut causer des ennuis.
Comme pour toutes les conventions, il vaut mieux qu'elles soient
rationnelles et bien étudiées. Moi ça ne me gêne pas trop de casser
la compatibilité si c'est pour éliminer une "fonctionnalité" un peu
trop contraignante, mais je ne pense pas que ce soit l'avis de tous,
et c'est compréhensible.

> On n'a pas le droit de faire des boucles portant un nom identique,
de
> toute façon.

Ca, il va bien falloir que ça change ! Sinon on galère quand on fait
sa
maquette avec des copier/coller d'exemples et de bouts de code !

Bof... Sinon, c'est dans le code que ça galère. Notamment au niveau
des boucles récursives. Si on change un peu la méthode de parsing,
ça risque de provoquer beaucoup de complications. Et il faut bien voir
que ce n'est pas vraiment un cadeau fait aux webmestres que d'autoriser
différentes boucles à porter le même nom : "bugs" silencieux et difficiles
à trouver dans les squelettes en perspective.

a+

Antoine.

PS : c'est bizarre quand même, cette erreur aurait dû dater de la 1.2 (nouveau
moteur), mais elle n'apparaît que maintenant sur la liste. Ou c'est moi qui
ne l'ai pas vue passer avant ?

9

@ Antoine Pitrou <pitrou@free.fr> :

Oui, c'est cela qu'il faut faire à mon avis : un message "caractère non
autorisé dans le nom de la boucle", ou équivalent.

Il suffit de l'installer en lieu et place de la ligne actuelle
    $id_boucle = ereg_replace("-","_",$id_boucle);

On peut aussi modifier l'ereg qui détecte la BOUCLE. Toutefois modifier
cette ereg fait juste que le boucle n'est pas détectée, et n'affiche pas de
message d'erreur (juste des tags spip non analysés). Vu le risque important
d'erreur, mieux vaut faire un cas particulier, non ?

PS : c'est bizarre quand même, cette erreur aurait dû dater de la 1.2 (nouveau
moteur), mais elle n'apparaît que maintenant sur la liste. Ou c'est moi qui
ne l'ai pas vue passer avant ?

Je l'ai retrouvée dans les archives : par exemple le message
<3C01F824.8070409@francenet.fr>, version 1.2.1. Mais puisqu'on n'avait
aucune idée de ce qui pouvait en être la cause, on n'y avait pas vraiment
prêté attention.

-- Fil

10

@ Fil <fil@rezo.net> :

On peut aussi modifier l'ereg qui détecte la BOUCLE. Toutefois modifier
cette ereg fait juste que le boucle n'est pas détectée, et n'affiche pas de
message d'erreur (juste des tags spip non analysés). Vu le risque important
d'erreur, mieux vaut faire un cas particulier, non ?

Bon, en fait non, donc il suffit de modifier l'ereg de la boucle, ce que je
viens de faire (inc-calcul-squel.php3).

En fait ce qu'on pourrait améliorer à ce propos c'est la tête des messages
d'erreur d'analyse de boucle : au lieu d'envoyer un simple "<H2>Erreur
machin : <BOUCLExxx>", appeler une fonction de signalement d'erreur qui

    1) affiche joliment (via le mal nommé inc-install ?)

    2) comporte un début d'explication plus clair, un bout de FAQ squelette,
    des liens vers l'aide en ligne [euh, non, ce lien aide en ligne devrait
    être dans inc-install de toutes façons] etc.

(je l'indique dans TODO.txt, pas le temps de coder)

-- Fil

11

Dans ce cas il faudra prévoir la possibilité de boucle de même nom,
sinon BOUCLE_je_m_apelle_toto et BOUCLE_je-m-apelle-toto auront le
même id_boucle. Et donc on aura des questions a priori tordues et
difficiles à débugguer sur spip@rezo.net :wink:

C'était juste un message comme ça... Mais c'est vrai que les boucles de
même nom seraient vraiment bienvenues et devraient pouvoir être possible
si on se lance dans la possibilité de faire des include dans les
squelettes.

Voilà.

12

Ouaip... d'accord.

Enfin pour penser aux includes (qui viendront bien un jour et seront
l'occasion de partager des "modules" intégrables à des squelettes entre
les webmestre), il faudra alors prévoir un truc genre "espace de
nommage" pour les boucles. C'est-à-dire que lors du include, les boucles
incluses soient renommées avec par exemple le nom du fichier inclu à la
suite, séparé du nom normal avec un code trop bizarre pour donner un nom
de boucle (ce qui donnerait des fonction PHP du genre
la_boucle_INCLUPAR_module() ).

A ce propos, quelqu'un travaille sur les includes en ce moment ?

a+

13

@ Thomas NOEL <thomas.noel@auf.org> :

les webmestre), il faudra alors prévoir un truc genre "espace de
nommage" pour les boucles. C'est-à-dire que lors du include, les boucles

Y'a pas une solution plutôt "programmation objet" ? Ce serait plus propre
que de bricoler des noms de fonction à rallonge. (Je dis ça, j'y connais
rien).

A ce propos, quelqu'un travaille sur les includes en ce moment ?

Je n'en ai pas l'impression.

-- Fil

14

A ce propos, quelqu'un travaille sur les includes en ce moment ?

Pas en ce moment, ma priorité actuelle étant aux locks, mais j'y
reviendrais bientôt.

Les discussions qui ont déjà eu lieu ont dégrossi le travail, mais
c'est pas encore vraiment ça ...