[spip-dev] modeles et compilation

Hello,

Les squelettes ont un cache php et les pages servies ont un cache html.
A chaque combinaison de valeurs des variables d'url correspond une page servie et un cache html
(aux var_xxx prés).

Dans le cas d'une page article simple par exemple, pour l'article 1126 on dira,
si on ajoute une variable supplémentaire dans l'url : 'depart' par exemple
les différentes valeurs de 'départ' générent des caches html différents.

En ce qui concerne les caches, j'ai compris qu'ils n'ont pas de cache qui leur soit propre.
Ils n'ont pas de cache html certainement.
Peut être ont-ils quand même un cache php ?

Dans le cas d'un modele inclu dans le texte de l'article 1126 cependant,
je ne sais pas quand le code php générant le html fournit par le modele est il compilé
(au moment du calcul du html de la page pour l'article 1126 ? et c'est recompilé si c'est utilisé dans un autre article ? ou bien alors il y a un cache php quand même ?)
mais en tout cas, le html en résultant est forcément calculé, lui,
au moment du calcul de la page id_article=1126...

Je suis confronté à une difficulté car je n'arrive pas à récupérer les variables d'url
à l'intérieur d'un modèle appelé à l'intérieur du texte d'un article.

Source du modele test.html :
EVAL{_request('depart')} = #EVAL{_request('depart')}<br/>
<?php echo "_GET['depart'] = ".($_GET['depart']); ?>

Ce modele est inséré en début de l'article 1126 par :
<test2011>

Si j'appelle une première fois la page avec ?id_article=1126&depart=1
l'affichage est :
     * EVAL{_request('depart')} = 1
     * _GET['depart'] = 1

Mais l'appel suivant avec ?id_article=1126&depart=222222
donne exactement le même résultat.

Pourtant ça devrait être un cache de page différent puisqu'il y a une combinaison d'url différente pour la page.
A moins que le compilateur très intelligent détecte que la variable n'est pas utilisée et l'exclue des aiguilleurs de cache ?
A moins qu'il faille comprendre 'différemment' le fait que les modeles "n'aient pas de cache" ?

Y a t il un moyen de s'en sortir pour que le modele affiche des trucs différents
selon les valeurs de la variable d'url 'depart'
sans modifier le squelette article.html de préférence ?

JLuc

Sur ce dernier point j'ai trouvé comment faire :
indiquer dans le mes_options.php que le cache vaut 0 pour l'id_article 1156...
ça me va ici, mais c'est difficilement généralisable.

J'ai par ailleurs trouvé ceci :
si j'insère le même <test2011> dans 2 articles 1156 et 1126,
ceux ci peuvent bien renvoyer des valeurs différentes.
Et si je RE-calcule l'un, alors l'autre sera également mis à jour au prochain affichage,
mais si je calcule seulement l'un, alors l'autre garde sa valeur.

Il semblerait y avoir un cache php.
Je me demande quelles autres conclusions en tirer...

JLuc

Ton problème est la démonstration du fait qu'il n'est pas possible, à ce jour, de récupérer des arguments du contexte dans un modèle inséré dans du texte.
Ce n'est pas juste un problème technique de récupération de l'argument par un _request bien senti, c'est un problème beaucoup plus général d'héritage du contexte qui sert à déterminer le cache.

Le cache ne se joue pas page par page, mais squelette par squelette, en fonction du env qui lui est passé.
Dans le cas particulier du squelette principal, le env est la traduction des variables dans l'url.

Un modèle n'a pas de cache intrinsèque, car son contenu est "imprimé" dans le cache du squelette qui le contient.

Dans ton cas, si tu mets ton modèle dans le texte d'un article, et que celui-ci apparait dans le #TEXTE d'un squelette B, le modèle sera inclus dans le cache de B.
Et c'est bien là qu'est le problème fondamental :
Ton modèle change si _request(depart) change, mais B n'a aucun moyen de le savoir. Par conséquent, même si B change, le cache de B ne changera pas, et ton modèle ne sera pas calculé.

Le seul moyen propre (mais couteux) de t'en tirer est ici de propager {env} à toutes tes inclusions, pour que tous les caches changent avec l'url de la page.

Cédric