Version 15 — December 2014 — JLuc
1 ) Eléments de grammaire
2 1 ) Erreurs du lexer ou du parser SPIP 2 ou 3
3 2 ) Erreurs non détectées, non signalées d’erreur
Jusqu’à présent, avec les éléments détaillé de grammaire, les erreurs signalées le sont à juste titre.
cf http://programmer.spip.net/Syntaxe-complete-des-balises
À l’intérieur d’une paire de {
et }
, il n’est pas nécessaire de poser des [( et )]
<BOUCLE_a(TABLE) {champ op #TRUC|filtre{param}}>
<:module:clef{arg1=txt, arg2=#BALISE}|filtre1{txt,#BALISE}|filtre2:>
Cependant, dans le cas de #SET ou #ARRAY il est nécessaire de poser les [( et )] à la balise elle-même si elle n’est pas utilisée comme argument d’une autre balise :
[(#SET{var, #BALISE|filtre{arg}})]
[(#ARRAY{1,a, 2,b, 3,#BALISE|filtre})]
Ainsi, pour le #GET, suivant où il est utilisé, il faudra ou non poser les [( et )] :
[(#GET{truc}|filtre)]
<BOUCLE_a(TABLE) {champ op #GET{truc}|filtre{param}}>
SPIP2 . 1 et SPIP3)
-* JLuc :
Les -* JLuc : les codes suivants provoquent une erreur du compilateur :
#SET{tel,[(#TEL|oui) telephone #TEL]}
#SET{mel,[(#WEB|non) [(#EMAIL|oui) mel #EMAIL]]}
L’erreur affichée est “Argument manquant dans la balise SET”.Par contre ça passe avec des crochets autour du SET. [(#SET{tel,[(#TEL|oui) telephone #TEL]
})] C’est “normal”.
Par contre ça passe avec des crochets autour du SET. [(#SET{tel,[(#TEL|oui) telephone #TEL]})]
Cette erreur est donc “normale”.
-* Habon :
<blockquote class="spip">
#ID_ANNONCE
n’est pas interprété :
#URL_ACTION_AUTEUR{
ajouter_lien,
annonce-#ID_ANNONCE-auteur-#SESSION{id_auteur}-candidater,
#SELF}
#ID_ANNONCE
est interprété :
#URL_ACTION_AUTEUR{
ajouter_lien,
auteur-#SESSION{id_auteur}-annonce-#ID_ANNONCE-candidater,
#SELF},
'
Si le #SESSION{id_auteur}
est un #NOM
,#ID_ANNONCE
est bien interprété. On dirait donc que c’est les arguments des balises:
- 2 balises avec des arguments, c’est bon.
- 2 balises sans arguments, c’est bon.
- Mais une balise avec et une balise sans, c’est pas bon.
Astuce trouvée : remplacer mon #ID_ANNONCE
par un #ENV{id_annonce}
, mais ça marche pas avec tous les contextes.
Rqsur ce dernier signalement : C’est une difficulté pour le créateur de squelette SPIP, mais cette difficulté ne peut elles pas être contournée normalement contournées en utilisant la syntaxe complète des balises, à savoir avec les crochets + parenthèses, autour de toutes les balises .
?
_ Normalement, c’est possible. _ Mais permettre l’écriture sans crochets parenthèses faciliterait l’écriture.
Les erreurs suivantes ne sont pas détectées ni signalées.
C’est probablement difficile à changer car tout ce qui n’est pas compris comme code SPIP est compris comme texte. Faudrait il que SPIP détecte “ce qui ressemble presque à un code mais n’en est pas un” pour le signaler et inviter à vérifier si c’est ya en fait une erreur dans ce qui devrait être un code ?
<INCLURE{fond=sla/main_head_fin.sla}}/>
aucune erreur n’est signalée mais ça comprend pas ce qu’il faut (il y a un en trop à la fin). <INCLURE
au début[avant (#VAL{arg}|unfiltre|#NOM_SITE_SPIP) après]
] aucune erreur signalée mais il manque un |sinon. SPIP pourrait éventuellement détecter que le résultat est ignoré et remplacé par une constante et présumer qu’il y a une erreur ?[(#BALISE|filtre{texte1,texte2})]
pose problème si il y a des virgules dans texte1 ou texte2 : cette virgule est considérée comme séparatrice des arguments du filtre. Même si on entoure les arguments avec #VAL{...}
, le problème persiste.