Déjà signalé il y a 6+ mois mais toujours présent.
Ca ne parse pas :
<BOUCLE_check_langue(CONDITION){si #LANG |=={#GET{langue}}}>
Ca parse mais ça renvoit n'importe quoi :
<BOUCLE_check_langue(CONDITION){si #LANG |=={#GET{langue}}>
A bientôt
Simon
Le 25 mars 10 à 09:17, Simon Camerlo a écrit :
Déjà signalé il y a 6+ mois mais toujours présent.
Ca ne parse pas :
<BOUCLE_check_langue(CONDITION){si #LANG |=={#GET{langue}}}>
et comme ça ?
{si (#LANG |=={#GET{langue}})}
Ca parse mais ça renvoit n'importe quoi :
<BOUCLE_check_langue(CONDITION){si #LANG |=={#GET{langue}}>A bientôt
Simon
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Pierre Fiches a écrit :
Le 25 mars 10 à 09:17, Simon Camerlo a écrit :
Déjà signalé il y a 6+ mois mais toujours présent.
Ca ne parse pas :
<BOUCLE_check_langue(CONDITION){si #LANG |=={#GET{langue}}}>et comme ça ?
{si (#LANG |=={#GET{langue}})}
Non plus, le seul contournement qui marche c'est d'inverser les paramètres pour ne plus avoir d'accolades incluses dans celles de l'opérateur de test :
<BOUCLE_check_langue(CONDITION){si #GET{langue} |=={#LANG}}>
Ca n'est pas toujours possible suivant le type de situation, et ça hypothèque pas mal l'utilisation des filtres |ou et |et dans cette boucle, pourtant c'est là qu'ils peuvent servir vraiment.
J'en profite pour rappeler qu'elle "casse" toujours régulièrement le contexte défini par la boucle englobante, obligeant à tout restocker dans des #SET...
Idem pour les #INCLURE appelés dans une boucle CONDITION : seul <INCLURE> est fiable.
++
Simon
Le 25/03/2010 09:29, Simon Camerlo a écrit :
Non plus, le seul contournement qui marche c'est d'inverser les
paramètres pour ne plus avoir d'accolades incluses dans celles de
l'opérateur de test ...
De manière générale ces questions de syntaxes mouvantes
(qui changent selon les contextes)
sont ce qu'il y a de pire dans l'utilisation de spip.
JL
Le 25/03/10 09:17, Simon Camerlo a écrit :
Ca ne parse pas :
<BOUCLE_check_langue(CONDITION){si #LANG |=={#GET{langue}}}>
on est bien d'accord : il n'y a pas d'espace entre la balise et le filtre ?
<BOUCLE_check(CONDITION){si #LANG|=={#GET{langue}}}>
(sinon évidemment : "Erreur(s) dans le squelette...")
Ca parse mais ça renvoit n'importe quoi :
<BOUCLE_check_langue(CONDITION){si #LANG |=={#GET{langue}}>
là, en revanche, sans l'espace inopportun tu aurais bien :
"BOUCLE_check: tag fermant manquant"
denisb a écrit :
Le 25/03/10 09:17, Simon Camerlo a écrit :
Ca ne parse pas :
<BOUCLE_check_langue(CONDITION){si #LANG |=={#GET{langue}}}>on est bien d'accord : il n'y a pas d'espace entre la balise et le filtre ?
<BOUCLE_check(CONDITION){si #LANG|=={#GET{langue}}}>(sinon évidemment : "Erreur(s) dans le squelette...")
!
!
Depuis quand ces espaces sont significatifs ??
La syntaxe des expressions balise + filtres est déjà super lourde, si on ne peut plus l'alléger un peu en insérant des espaces là...
Tiens, au passage, une autre bizarrerie syntaxique :
<div class="#GET{toto} tutu">
Génère parfois une erreur "filtre tutu introuvable" alors même qu'il n'y a pas le pipe d'introduction d'un filtre...
++
Simon
Salut,
Le 25/03/2010 10:31, Simon Camerlo a écrit :
Tiens, au passage, une autre bizarrerie syntaxique :
<div class="#GET{toto} tutu">
Génère parfois une erreur "filtre tutu introuvable" alors même qu'il n'y
a pas le pipe d'introduction d'un filtre...
<div class="[(#GET{toto}) ]tutu">
et hop
++
b_b
Bruno Bergot a écrit :
Salut,
Le 25/03/2010 10:31, Simon Camerlo a écrit :
Tiens, au passage, une autre bizarrerie syntaxique :
<div class="#GET{toto} tutu">
Génère parfois une erreur "filtre tutu introuvable" alors même qu'il n'y
a pas le pipe d'introduction d'un filtre...<div class="[(#GET{toto}) ]tutu">
et hop
Oui, bien sûr, mais ça reste une aberration syntaxique qui force à alourdir le code pour contourner ce qui est à mes yeux un bug.
++
Simon
On 25/03/10 10:31, Simon Camerlo wrote:
Depuis quand ces espaces sont significatifs ??
Depuis un certain temps 
http://trac.rezo.net/trac/spip/ticket/820
Paolo
Re,
Le 25/03/2010 10:31, Simon Camerlo a écrit :
Depuis quand ces espaces sont significatifs ??
La syntaxe des expressions balise + filtres est déjà super lourde, si on
ne peut plus l'alléger un peu en insérant des espaces là...
Depuis toujours si je ne me trompe pas. La doc dit bien :
Dans SPIP, on peut directement appliquer des filtres aux éléments récupérés de la base de données, en les indiquant dans la syntaxe des balises SPIP, qui devient :
[ option avant (#BALISE|filtre1|filtre2|...|filtren) option après ]
La syntaxe est donc de faire suivre le nom de la balise, entre les parenthèses, par les filtres succesifs, séparés par une barre verticale (nommée habituellement pipe).
Devrions-nous y ajouter qu'il ne faut pas d'espace entre la balise et le pipe ?
++
b_b
Le 25/03/10 10:31, Simon Camerlo a écrit :
Depuis quand ces espaces sont significatifs ??
depuis l'utilisation de cette fonctionnalité précise dans ce
*plugin* précis.
ici nous sommes dans une syntaxe particulière.
si, pour spip, un critère de boucle, c'est :
un champ sql - un opérateur - une valeur
(oui je sais, sauf certains critères particuliers :
par ..., inverse, et quelques autres clairement documentés)
le *plugin* bonux utilise une toute autre syntaxe pour les
critères de ses boucles à lui.
La syntaxe des expressions balise + filtres est déjà super lourde, si on
ne peut plus l'alléger un peu en insérant des espaces là...
pas dans les boucles *spécifiques* de bonux.
<div class="#GET{toto} tutu">
Génère parfois une erreur "filtre tutu introuvable" alors même qu'il n'y
a pas le pipe d'introduction d'un filtre...
oui. c'est encore autre chose.
#GET{toto} 'mange' l'espace qui le suit (tout comme #ENV{toto})
si : #SET{toto, abc}
alors : #GET{toto} 123
produira : abc123
au lieu de : abc 123
*SAUF* si on écrit (comme on le devrait) : [(#GET{toto})] 123
voire : [(#GET{toto}) ]123
ou : [(#GET{toto}) 123]
(ces 2 dernières écritures *conditionnant* l'affichage de l'espace
ou de l'espace puis 123 à l'existence de toto)
Le 25/03/10 11:10, Bruno Bergot a écrit :
Depuis toujours si je ne me trompe pas. La doc dit bien :
non mais là, le sujet c'est bien :
'dans l'utilisation d'un critère de boucle'
comme je le dis plus haut (plus bas pour ceux qui classent
leurs news à l'envers...) spip n'utilise *jamais* de
balise en premier argument d'un critère :
on n'a *jamais* {#TITRE = me voilà}
bonux, lui, pour ses boucles à lui (qu'il est le seul à les avoir)
utilise une *autre* syntaxe : la sienne.
Devrions-nous y ajouter qu'il ne faut pas d'espace entre la balise et le
pipe ?
hem hem...
<BOUCLE_b(ARTICLES) {id_article < 10}>
[(#TITRE |supprimer_numero)]<br />
</BOUCLE_b>
#SET{toto, abc}
[(#GET{toto} |strtoupper)]
ça fonctionne bien hein !
(/me déjà dehors et loin...)
Bruno Bergot a écrit :
Le 25/03/2010 10:31, Simon Camerlo a écrit :
Depuis quand ces espaces sont significatifs ??
La syntaxe des expressions balise + filtres est déjà super lourde, si on
ne peut plus l'alléger un peu en insérant des espaces là...Depuis toujours si je ne me trompe pas. La doc dit bien :
Dans SPIP, on peut directement appliquer des filtres aux éléments récupérés de la base de données, en les indiquant dans la syntaxe des balises SPIP, qui devient :
[ option avant (#BALISE|filtre1|filtre2|...|filtren) option après ]
La syntaxe est donc de faire suivre le nom de la balise, entre les parenthèses, par les filtres succesifs, séparés par une barre verticale (nommée habituellement pipe).
La syntaxe des balises SPIP - SPIP
Devrions-nous y ajouter qu'il ne faut pas d'espace entre la balise et le pipe ?
Voici un extrait d'un de mes modèles :
#SET{largeur_max,500}
#SET{largeur_min,150}
[(#SET{l,#ENV{l,#ENV{L,#MODE|=={image}
|?{#LARGEUR,#LOGO_DOCUMENT||extraire_attribut{width}}}}
|min{#GET{largeur_max}}
|max{#GET{largeur_min}}})]
[(#SET{h,#ENV{h,#ENV{H,#HAUTEUR}}})]
[(#ENV{lien} |=={''}
|?{ [(#MODE|=={image}
|?{ [(#GET{l}
|min{#GET{largeur_max}}
|>={#LARGEUR}
|et{#GET{h} |=={''}
|ou{#GET{h} |>={#HAUTEUR}}
}
|?{#SET{lien,non}})]
})]
})]
Illustration que les espaces et saut de lignes sont autorisés (encore heureux !) dans les expressions balises + filtres.
Si je devais compresser ça, je te laisse imaginer à quel point la lisibilité (déjà assez... rugueuse) de ce code en souffrirait.
A bientôt
Simon
denisb a écrit :
Le 25/03/10 10:31, Simon Camerlo a écrit :
Depuis quand ces espaces sont significatifs ??
depuis l'utilisation de cette fonctionnalité précise dans ce
*plugin* précis.ici nous sommes dans une syntaxe particulière.
si, pour spip, un critère de boucle, c'est :
un champ sql - un opérateur - une valeur
(oui je sais, sauf certains critères particuliers :
par ..., inverse, et quelques autres clairement documentés)le *plugin* bonux utilise une toute autre syntaxe pour les
critères de ses boucles à lui.
Oui, c'est pour ça que je poste ces remarques sur la zone, pas sur spip-dev.
Il est à mon avis important que les squelettes étendant les instructions du langage de squelette respectent la grammaire de base dudit langage, sinon on ne s'y retrouve plus.
J'ai d'autre-part suivi de nombreuses discussions qui parlaient d'intégrer la plupart des fonctionnalités de bonux dans le core pour al prochaine release, donc...
Et enfin, je milite pour la transformation de la boucle CONDITION et de la boucle POUR en <CONDITION{#TOTO |=={1}}> et <POUR{#GET{mon_tableau}}>, ça allègerait beaucoup la syntaxe <troll> et spip en a besoin </troll>
<div class="#GET{toto} tutu">
Génère parfois une erreur "filtre tutu introuvable" alors même qu'il n'y
a pas le pipe d'introduction d'un filtre...oui. c'est encore autre chose.
#GET{toto} 'mange' l'espace qui le suit (tout comme #ENV{toto})si : #SET{toto, abc}
alors : #GET{toto} 123
produira : abc123
au lieu de : abc 123
*SAUF* si on écrit (comme on le devrait) : [(#GET{toto})] 123voire : [(#GET{toto}) ]123
ou : [(#GET{toto}) 123]
(ces 2 dernières écritures *conditionnant* l'affichage de l'espace
ou de l'espace puis 123 à l'existence de toto)
Bien sûr, c'est le contournement que j'utilise pour éviter ça.
Cependant on est typiquement dans le cas d'un alourdissement inutile de la syntaxe qui nuit à la facilité de prise en main de spip (j'essaie autant que possible de promouvoir spip pour ses immenses qualités, mais la plupart des développeurs à qui j'essaie de le présenter font la grimace, poussent des cris, tombent dans les vapes voire se suicident quand je leur montre ça. J'exagère à peine
Dans mon expérience personnelle (3 ans de spip sur des projets assez importants), le triple parenthésage est inutile dans 99% des cas où je suis obligé de l'utiliser dans le code de mes squelettes.
Un simple (au pire double) parenthésage suffirait dans la plupart des cas. Combien de vos expressions commencent par [(# et se terminent par })] ?
Une meilleure stratégie d'utilisation des séparateurs "naturels" que sont # et | me semble possible pour éviter d'infliger ça quand ce n'est pas absolument nécessaire.
M'enfin, c'est un vieux serpent de mer qui ressort au printemps, je renvoie les gens intéressés à une proposition de syntaxe alternative que j'avais faite sur la liste dev il y a un an...
A bientôt
Simon