Le 15/09/2016 à 11:57, Cédric Morin a écrit :
Et ton article wiki donne un exemple très précis de pourquoi c'est pas 
forcément une bonne idée, ou un piège.
Tu as écris [(#_VISITEUR{nom}|strlen)]
ce qui PRECISEMMENT est impossible avec ce genre de balise qui produit du PHP. 
Ton filtre s'applique donc sur le PHP et
renvoie le strlen du code PHP, pas du tout le strlen du nom du visiteur.
Ce type de balise ne supportera aucun filtre ni aucun affichage conditionnel 
entre crochets - ou plutot le compilateur
ne dira rien mais ça ne produira qu'un résultat innatendu et piégeux.


Oui tout à fait et c'est justement pour illustrer ce comportement piégeux qu'il 
y a ce code dans l'exemple !
Cf les explications : "Par exemple <code>[(#VISITEUR{nom}|strlen)]</code> renvoie toujours 33, quel que soit le nom de la personne connectée."
(Visiblement ça suffit pas, je vais dupliquer l'avertissement dans le squelette 
de test !)

En l'état je préfère nettement conserver le PHP explicite dans le squelette 
pour ce besoin plutot que planquer ça dans
une fausse balise qui a un comportement dérogatoire.

Je suis d'accord qu'il faut pas planquer, justement pour éviter les erreurs.
Mais j'aime pas du tout casser la structure un code html + spip avec des structures php. Ça me donne vraiment l'impression qu'il manque quelque chose : cette couche dont ces 1ères macros sont une première brique.
Donc ces balises visent pas à planquer pas le php, elles visent à simplifier 
les bonnes pratiques,
à aider à penser des pages personnalisées et à structurer le html+spip d'une 
manière plus lisible.

Justement pour pas que ça soit planqué, le nom est préfixé par un _ :
ça ne peut pas passer inaperçu même du webmaster le moins attentif, qui se posera la 
question "pourquoi".

Et si ce _ est généralisé pour d'autres macros qui existeraient actuellement ou plus tard alors ce sera encore mieux. #nomenklatura

Ensuite pour ta question qui concerne l'affichage de données liées à 
l'utilisateur, 2 possibilités :
- soit c'est une donnée présente dans la globale visiteur_session et elle peut 
s'afficher en PHP sans impact sur le cache
- soit c'est une donnée qui nécessite une boucle et il faut passer par un 
#SESSION{id_auteur} et donc un cache par session.

Par ailleurs attention, tes propositions de balise utilisent session_get qui 
n'est pas par défaut dans les fonctions
chargées en mémoire pour les visiteurs anonymes. Ton squelette produira page 
blanche pour un visiteur anonyme. Je pense
qu'il vaut mieux mentionner explicitement la globale visiteur_session dans le 
code PHP généré

C'est pour cela que le 2eme bloc de code commence par 
"include_spip('inc/session');"

Mais encore une fois je suis pas fan de ce type de balises, sauf à ce que le 
compilateur les gère et refuse les filtres
et affichages conditionnels en les sanctionnant d'une erreur.

Bonne idée.

JL

 il y a d'autres besoins :

- des appels de filtres, qui transforment la valeur sessionnée avant de la 
tester ;
- notamment pour, à partir de l'id_auteur, accéder à d'autres informations
  situées en BDD locale ou distante
  car pour des pages personnalisées il y a des données riches autour des 
visiteurs ;

- des comparaisons autres que "non nul" ou "égal à " : >, in_array, <=, etc ;

- l'utilisation dans les critères, typiquement {id_auteur=#SESSION{id_auteur}}.

Il me semble que ça apporterait un gros plus pour ces sites...
sauf si vous me montrez qu'il y a une faille vis a vis du cache ou d'un autre 
mécanisme spip !
Vos avis retours et expériences sont bienvenus
(et que pense la nomenklatura du principe général de préfixer le nom des 
balises macro par un _ ?)

Enfin, je sens qu'il y a encore des besoins non satisfaits et des outils à 
créer :
- pour les données étendues relatives aux visiteurs : quels outils sympas pour 
relier les sessions à ces données étendues ailleurs, de manière efficace et 
accessible dans les squelettes SPIP ? Comment les cacher ? rafraîchir le cache 
de manière ciblée ?
- pour diagnostiquer un site relativement au cache, à son éclatement ou à 
l'efficacité des squelettes

JLuc


----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Répondre à