Author: denisb@laposte.net
Date: 2009-09-04 01:31:37 +0200 (ven, 04 sep 2009)
New Revision: 14459
Log:
corrige l'affichage systématique (même si l'on n'est pas loggué) des parties conditionnelles de la balise [aff_cond (#URL_LOGOUT) aff_cond] (mais ça me semble plus une rustine qu'une réparation véritable...)
Modified:
branches/spip-2.0/ecrire/balise/url_logout.php
comme toutes les balises dynamiques,
#URL_LOGOUT produit du php et non un texte, et son retour n'est donc jamais vide.
Les parties conditionnelles sont donc toujours affichées.
De fait, introduire un comportement dérogatoire n'est pas une bonne idée, amha
Cédric
Le 4 sept. 09 à 01:31, denisb@laposte.net a écrit :
Author: denisb@laposte.net
Date: 2009-09-04 01:31:37 +0200 (ven, 04 sep 2009)
New Revision: 14459Log:
corrige l'affichage systématique (même si l'on n'est pas loggué) des parties conditionnelles de la balise [aff_cond (#URL_LOGOUT) aff_cond] (mais ça me semble plus une rustine qu'une réparation véritable...)Modified:
branches/spip-2.0/ecrire/balise/url_logout.phpDetails: http://trac.rezo.net/trac/spip/changeset/14459
_______________________________________________
spip-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-commit
dev: http://trac.rezo.net/trac/spip/
comme toutes les balises dynamiques,
#URL_LOGOUT produit du php et non un texte, et son retour n'est donc jamais vide.
Les parties conditionnelles sont donc toujours affichées.De fait, introduire un comportement dérogatoire n'est pas une bonne idée, amha
Cédric
oui. tu as raison. c'est dérogatoire. fausse bonne idée donc.
je nettoie
(et j'ajoute plutôt de la doc qui va bien...)
--
@@@@@
E -00 comme on est very beaux dis !
' `) /
|\_ ==" { denisb @ laposte.net }
comme toutes les balises dynamiques,
#URL_LOGOUT produit du php et non un texte, et son retour n'est donc jamais vide.
Les parties conditionnelles sont donc toujours affichées.
rhââââ
[j'existe !(FORMULAIRE_INEXISTANT)]
ne m'affichera j'existe *que* si FORMULAIRE_INEXISTANT existe (!)
et *rien* le cas échéant.
grâce à :
!find_in_path('formulaires/'.$form.'.html')
dans function balise_FORMULAIRE__dist()
donc, finalement, pas si dérogatoire que ça...
--
@@@@@
E -00 comme on est very beaux dis !
' `) /
|\_ ==" { denisb @ laposte.net }
De fait, introduire un comportement dérogatoire n'est pas une bonne idée, amha
je ne veux *surtout pas* donner l'impression de m'acharner...
[multi (#MENU_LANG)]
n'affichera multi (plus le menu des langues) *que* si le site a été configuré en multilangues
et que spip_meta.langues_multilingue est remplie d'au moins 2 langues (xx, yy)
--
@@@@@
E -00 comme on est very beaux dis !
' `) /
|\_ ==" { denisb @ laposte.net }
-----Message d'origine-----
De : cedric.morin@yterium.com [mailto:cedric.morin@yterium.com]
Envoyé : vendredi 4 septembre 2009 08:52
À : denisb@laposte.net
Cc : spip-commit@rezo.net
Objet : Re: [spip-commit] r14459 - branches/spip-2.0/ecrire/balisecomme toutes les balises dynamiques,
#URL_LOGOUT produit du php et non un texte, et son retour
n'est donc jamais vide.
Les parties conditionnelles sont donc toujours affichées.De fait, introduire un comportement dérogatoire n'est pas une
bonne idée, amha Cédric
En l'espère, le comportement dérogatoire, c'est le fait qu'une balise vide
affiche quand même le code conditionnel, nous avons été 3 à nous casser la
tête sur le problème. Je ne crois pas être complètement débutant en SPIP,
mais une balise vide qui affichait quand même le code conditionnel, je ne
l'avais jamais vu, et j'y ai vu un bug.
De plus, si le comportement actuel des balises dynamique doit persister, il
faut absolument complèter la documentation des balises
(La syntaxe des balises SPIP - SPIP) pour signaler les exceptions.
Et je crois enfin que la subtilité entre "n'existe pas" et "existe mais est
vide" est beaucoup trop compliquée pour les débutants qui seront perdus par
ces comportements déviants (pourquoi devoir faire une gestion compliquée
avec #SESSION du cas de #URL_LOGOUT vide alors qu'il ne faut pas le faire
pour #TEXTE ?).
D'ailleurs, ce "correctif" est faux, puisque balise_URL_LOGOUT_stat est appelée à la compilation et non à l'execution.
Autrement dit, si le squelette est compilé par un visiteur non logé, personne n'aura jamais l'url de logout
Et réciproquement, si le squelette est compilé par un visiteur logé, le comportement est identique à avant.
La raison même pour laquelle une balise dynamique produit du php est pour l'évaluer au service de la page, hors cache.
Cédric
Le 4 sept. 09 à 01:31, denisb@laposte.net a écrit :
Author: denisb@laposte.net
Date: 2009-09-04 01:31:37 +0200 (ven, 04 sep 2009)
New Revision: 14459Log:
corrige l'affichage systématique (même si l'on n'est pas loggué) des parties conditionnelles de la balise [aff_cond (#URL_LOGOUT) aff_cond] (mais ça me semble plus une rustine qu'une réparation véritable...)Modified:
branches/spip-2.0/ecrire/balise/url_logout.phpDetails: http://trac.rezo.net/trac/spip/changeset/14459
_______________________________________________
spip-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-commit
dev: http://trac.rezo.net/trac/spip/
Le 4 sept. 09 à 12:24, Olivier GENDRIN a écrit :
-----Message d'origine-----
De : cedric.morin@yterium.com [mailto:cedric.morin@yterium.com]
Envoyé : vendredi 4 septembre 2009 08:52
À : denisb@laposte.net
Cc : spip-commit@rezo.net
Objet : Re: [spip-commit] r14459 - branches/spip-2.0/ecrire/balisecomme toutes les balises dynamiques,
#URL_LOGOUT produit du php et non un texte, et son retour
n'est donc jamais vide.
Les parties conditionnelles sont donc toujours affichées.De fait, introduire un comportement dérogatoire n'est pas une
bonne idée, amha CédricEn l'espère, le comportement dérogatoire, c'est le fait qu'une balise vide
affiche quand même le code conditionnel, nous avons été 3 à nous casser la
tête sur le problème. Je ne crois pas être complètement débutant en SPIP,
mais une balise vide qui affichait quand même le code conditionnel, je ne
l'avais jamais vu, et j'y ai vu un bug.
C'est au compilateur de refuser les parties conditionnelles sur les balises vides, comme il le fait en branche dev pour les filtres
Car le prolongement logique de cette discussion serait
ah mais
[(#URL_LOGOUT|sinon{connectez-vous})]
ne marche pas non plus.
Et la réponse est la même : une balise dynamique ne peut pas gérer de contenu alternatif ni de filtres.
Emmanuel nous dirait surement que l'erreur est d'avoir adopté le même syntaxe et de ne pas avoir différencié les deux types de balises (celles qui produisent du contenu, et celles qui produisent du php qui produira du contenu a l'execution).
Cédric
Le 4 sept. 09 à 12:34, cedric.morin@yterium.com a écrit :
C'est au compilateur de refuser les parties conditionnelles sur les balises vides, comme il le fait en branche dev pour les filtres
Je voulais dire
sur les balises *dynamiques* ...
Le 4 sept. 09 à 12:34, cedric.morin@yterium.com a écrit :
Emmanuel nous dirait surement que l'erreur est d'avoir adopté le même syntaxe et de ne pas avoir différencié les deux types de balises (celles qui produisent du contenu, et celles qui produisent du php qui produira du contenu a l'execution).
Exact. Lorsque j'ai terminé la réécriture des balises dynamiques pour SPIP 1.8, je suis arrivé à la conclusion qu'il s'agissait finalement d'une inclusion de squelettes qu'on soumettait à condition et pour laquelle le contexte était spécifié par une fonction PHP (BALISE_stat), alors que les inclusions explicites sont inconditionnelles et précisent le contexte au niveau du squelette. Partant, je serais pour une syntaxe unifiée de toutes les formes d'inclusion, sans confusion possible avec l'extraction de champ SQL comme c'est le cas actuellement.
Committo,Ergo:Sum
D'ailleurs, ce "correctif" est faux, puisque balise_URL_LOGOUT_stat est appelée à la compilation et non à l'execution.
bon ok.
ça a fini par rentrer...
nettoyé donc par : http://trac.rezo.net/trac/spip/changeset/14462/branches
j'ai aussi retouché la doc : Les formulaires - SPIP
--
@@@@@
E -00 comme on est very beaux dis !
' `) /
|\_ ==" { denisb @ laposte.net }
j'ai aussi retouché la doc : Les formulaires - SPIP
Il faut aussi mettre un avertissement sur
La syntaxe des balises SPIP - SPIP à ce sujet, et on voit bien à la
modification que tu as faite dans 1827 que le principe est problèmatique par
nature, puisqu'il oblige à introduire du PHP dans le squelette dès qu'on
veut permettre à un utilisateur de se connecter/déconnecter
([(#LOGIN_PUBLIC|sinon{#URL_LOGOUT})] ne fonctionnerait pas ?).
puisqu'il oblige à introduire du PHP dans le squelette
non (heureusement !)
[<a href="(#SESSION|oui)#URL_LOGOUT">déconnection</a>]
--
@@@@@
E -00 comme on est very beaux dis !
' `) /
|\_ ==" { denisb @ laposte.net }
[<a href="(#SESSION|oui)#URL_LOGOUT">déconnection</a>]
m'enfin X denis X
/me minute c..c...
-----Message d'origine-----
De : cedric.morin@yterium.com [mailto:cedric.morin@yterium.com]
Envoyé : vendredi 4 septembre 2009 12:34
Car le prolongement logique de cette discussion serait ah
mais [(#URL_LOGOUT|sinon{connectez-vous})]
ne marche pas non plus.
Et la réponse est la même : une balise dynamique ne peut pas
gérer de contenu alternatif ni de filtres.
Moi je dis juste que la doc des balises n'est pas à jour sur ce point, elle
ne distingue/signale pas les statiques et les dynamiques 
S'lt
Moi je dis juste que la doc des balises n'est pas à jour sur ce point, elle
ne distingue/signale pas les statiques et les dynamiques
Tu sais où se trouve le site de documentation spip.net et la bonne
rubrique (SPIP)
A toi d'ouvrir la bal
Tu sais où se trouve le site de documentation spip.net et la
bonne rubrique
(SPIP)
Je parlais plutôt de La syntaxe des balises SPIP - SPIP, mais je vais
essayer de faire quelque chose là où tu me l'indique.