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.

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.

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é

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.

--
Cédric



JLuc a écrit :
Hello

Suite à la question de Klaus, aux explications de Cerdic,
à mes insatisfactions dans le développement d'un site "massivement"
personnalisé
et avec l'aide de marcimat hier soir, j'ai créé quelques balises
pour cette couche de "php recommandé dans le squelette" à la place des
#SESSION, #AUTORISER
et aussi à la place des <?php if ($GLOBALS['visiteur_session'] qui
cassent le code SPIP.

#_VISITEUR
#_VISITEUR_SI
#_VISITEUR_SI_EGAL
#_VISITEUR_SINON
#_VISITEUR_FINSI

Ces balises améliorent la lisibilité du code et rendent la
recommandation plus accessible.

Ce sont des balises qui n'en sont pas vraiment,
puisque elles insèrent dans le html du cache non le résultat à afficher,
mais un code <?php ... ?>, comme s'il avait été écrit dans le squelette.
Donc ce sont plutôt des macros.
Pour bien expliciter ce fonctionnement particulier, qui a des conséquences,
leur nom est préfixé par un _ :

Pour l'instant le code, des explications et un squelette de test sont
dans le carnet :
https://contrib.spip.net/4823

J'aimerais encore ajouter à ce code des détection de mauvaises imbrication
et signalement d'erreurs, car actuellement c'est page blanche en cas
d'erreur.

Ces macros couvrent 100% des besoins du squelette spir_doc qui motivait
la question de Klaus.
Mais spipr-doc est un squelette peu personnalisé et sur d'autres
squelettes, 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
----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Répondre à