Committo,Ergo:sum disait :
> cette balise n'inclut plus d'office la langue dans le contexte.
Bonjour,
Excuse-moi que je n'arrive à tester cela avec un peu de retard...
Le premier problème/différence que je trouve est que ce n'est pas seulement la langue qui n'est plus passée, mais #ENV{date} est aussi vide -- ce qui n'était pas le cas auparavant.
Devrais-je corriger les squelettes pour ajouter la date, ou est-ce une erreur à corriger ?
merci, Paolo
Paolo wrote:
Le premier problème/différence que je trouve est que ce n'est pas seulement la langue qui n'est plus passée, mais #ENV{date} est aussi vide -- ce qui n'était pas le cas auparavant.
Ah, en fait, le problème touche peut-être plutôt la balise #ENV{date}
Je mets dans un squelette de 1er niveau la ligne : // #ENV{date} //
et je reçois :
SPIP 2.0 (branche beta) :
// 2008-09-05 16:06:52//
--ce qui est le résultat attendu (bien qu'avec une espace mangée ?)
mais avec SPIP 2.0 dev (12539) c'est vide :
// //
Paolo
Si tu as vu passer le message de Cédric, tu as du voir qu'il y a débat.
Le fait de rajouter automatiquement lang, date et date_redac dans le contexte d'une inclusion a des avantages, mais aussi un inconvénient: ne pas pouvoir utiliser les critères condtionnels {lang ?} {date ?} ou {date_redac ?} dans le cadre d'une inclusion.
Jusqu'à présent, <INCLURE> et #INCLURE étaient réputés se compiler pareillement, la première insèrant le résultat PHP de la compilation (donc réexécuté à chaque requete HTTP), la deuxième insérant le résultat HTML du résultat de la compilation PHP (donc exécuté une seule fois).
Bien que la compilation soit la même, les pages rendues par les deux constructions ne vont pas forcément être les mêmes parce que à chaque nouvelle exécution, la base de données peut avoir changé (et aussi parce que le squelette peut utiliser le NOW() SQL d'une manière ou d'une autre).
J'ai profité de ces différences (aspect bien connu en théorie de la compilation) pour en ajouter une autre, afin de combler le manque de critère conditionnel sur ces 3 champs dans #INCLURE tout en laissant le comportement inchangé dans <INCLURE>. On a donc une fonctionnalité de plus dans SPIP sans en avoir une de moins, mais au prix d'un incompatibilité de #INCLURE. Dans les squelettes utilisant #INCLURE, il faut donc soit le remplacer par <INCLURE...> soit lui rajouter {lang){date}{date_redac}. Personnellement je trouve ce prix à payer normal pour l'ajout de cette fonctionnalité.
Committo,Ergo:Sum
Salut,
Je ne sais pas si c'est intéressant sur ce sujet, mais bon...
=> En ce moment, je bosse sur un serveur qui a de gros soucis de tenue en charge. Il semble que ça coince avec le cache. Pas très précis, m'enfin c'est la piste principale.
=> Bref, je suis en train de remplacer les <INCLURE> par des #INCLURE. Car ce que je me demande: est-ce que le fait d'avoir une inclusion dynamique ne multiplie pas les calculs de SPIP lors de la visite d'une seule page contenant des <INCLURE> (si je ne me trompe: on teste le cache de la page principale, puis ensuite les caches des fichiers inclus), alors qu'en remplaçant tout par des #INCLURE, tout est envoyé d'un seul coup.
=> Emmanuel, je n'ai pas bien pigé si tu avais supprimé la différence entre <INCLURE> et #INCLURE, et si oui quel est le fonctionnement désormais (dynamique ou statique).
ARNO*
Avant, <INCLURE> était équivalent à #INCLURE moins la mise en cache.
A présent, <INCLURE> est plus précisément équivalent à #INCLURE{lang}{date}{date_redac}
c'est-à-dire qu'il faut mettre explicitement ces 3 valeurs de contexte si on en a besoin,
cette explicitation étant la contrepartie de pouvoir enfin utiliser un critère conditionnel dessus.
Au niveau des perfomances, ma modif est nulle.
En y repensant, il y a un point là-dessus dont on n'a pas parlé et qui mérite discussion.
Quand on utilse {env} dans #INCLURE, l'implémentation recopie l'environnement d'appel,
dans lequel ne figure pas forcément lang, date et date_redac,
mais auparavant ils étaient mis juste après si absent.
Ce qu'on peut faire, c'est de dire que {env} dans #INCLURE rajoute aussi ces 3 valeurs.
On aurait alors l'équivalence <INCLURE> = #INCLURE{env}
ce serait plus facile pour adapter ses squelettes à la nouvelle possibiltié de #INCLURE d'avoir
ces 3 valeurs comme criteres conditionnels.
En contrepartie, l'écriture #INCLURE{env}{lang ?} ne marcherait pas.
Ca se discute.
Committo,Ergo:Sum
* Committo,Ergo:sum tapuscrivait, le 05/09/2008 18:14:
En y repensant, il y a un point là-dessus dont on n'a pas parlé et qui mérite discussion.
Quand on utilse {env} dans #INCLURE, l'implémentation recopie l'environnement d'appel,
dans lequel ne figure pas forcément lang, date et date_redac,
mais auparavant ils étaient mis juste après si absent.
Ce qu'on peut faire, c'est de dire que {env} dans #INCLURE rajoute aussi ces 3 valeurs.
On aurait alors l'équivalence <INCLURE> = #INCLURE{env}
ce serait plus facile pour adapter ses squelettes à la nouvelle possibiltié de #INCLURE d'avoir
ces 3 valeurs comme criteres conditionnels.
En contrepartie, l'écriture #INCLURE{env}{lang ?} ne marcherait pas.
Ca se discute.
Je vais peut-être dire une bêtise, mais {lang ?} est une écriture qui signifie : filtrer sur lang si ce dernier est défini.
Est-ce que dans le passage de paramètres, on ne pourrait pas aussi utliser {lang ?} pour ne passer ce dernier que si défini ?
Ou mieux encore, le passer par défaut (et les 2 autres aussi), sauf s'il est indéfini au sens de {lang ?}
Je suis pour une solution qui réalise la plus grande flexibilité possible. Donc en principe pour #INCLURE{env}{lang ?}.
Puis:
En y repensant, il y a un point là-dessus dont on n'a pas parlé et qui mérite discussion.
Quand on utilse {env} dans #INCLURE, l'implémentation recopie l'environnement d'appel,
dans lequel ne figure pas forcément lang, date et date_redac,
mais auparavant ils étaient mis juste après si absent.
Ce qu'on peut faire, c'est de dire que {env} dans #INCLURE rajoute aussi ces 3 valeurs.
Où #INCLURE irait-t-il chercher les valeurs pas présents dans le contexte? Cettte approche ne serait-elle pas équivalente à
#INCLURE{env}{lang ?}{date ?}{date_redac ?} ?
On aurait alors l'équivalence <INCLURE> = #INCLURE{env}
ce serait plus facile pour adapter ses squelettes à la nouvelle possibiltié de #INCLURE d'avoir
ces 3 valeurs comme criteres conditionnels.
En contrepartie, l'écriture #INCLURE{env}{lang ?} ne marcherait pas.
Ca se discute.
S'il es possible de supprimer le contexte de langue (ou un autre) dans le squelette appellé par une boucle du genre
<BOUCLE_xyz(ARTICLES){id_article}{#ENV{langue=""}}> je serais pour la solution transmettant automatiquement lang. Mais je doute que ce soit possible (d'ailleurs mon code techniquement c'est n'importe quoi, juste pour donner une idée).
Sinon je le trouverait préférable que #INCLURE transmette langue comme paramètre optionnel ( #INCLURE{lang=en} ) qui serait rajouté automatiquement à {env} qui serait invisible dans le code mais exécuté quand même.
merci, klaus++
Je reprends langue ...
J'ai l'impression que le débat est un peu faussé parce qu'il y a un point méconnu de SPIP qui vient tout à coup de surgir,
j'expose plus précisément le avant/après de la chose.
AVANT:
quand SPIP calcule une page à partir d'un squelette il construit un contexte à partir de la QUERY_STRING (éventuellement codée par les URLs propres etc, mais c'est transparent) et il ne rajoute AUCUN autre paramètre.
En revanche, quand il exécute un <INCLUDE> ou #INCLUDE présent dans ce squelette principal (ou une sous-inclusion) il rajoute d'office les paramètres lang, date et date_redac. Point important: si ces paramètres n'étaient pas présents, des valeurs par défaut sont prises, savoir
$GLOBALS['spip_lang'] et time(). On voit donc que les criteres conditionnels {lang ?} {date ?} {date_redac ?} seront inopérants dans le squelette inclus car au pire il y aura la valeur par défaut. Le compilateur pourrait même dire à l'auteur du squelette de revoir sa copie en présence de ces critères conditionnels.
MAINTENANT:
Pour pouvoir disposer de ces critères à l'inclusion, SPIP ne place plus d'office ces 3 valeurs dans le cas de #INCLUDE, mais continue à le faire pour <INCLURE> pour minimiser l'impact en terme ce compatibilité ascendante.
Rétrospectivement, je pense que SPIP n'aurait pas dû ajouter d'office des paramètres, ou au moins ne pas le faire quand il n'y a rien d'autres que des valeurs par défaut (elles auraient pu être insérées ultérieurement aux seuls moments où elles deviennent indispensables). Maintenant que les habitudes sont prises, il faut rajouter la possibilitié des critères conditionnels en limitant au minimum l'impact en terme de compatibilité. La solution présente dans la dev aujourd'hui me semble le meilleur compromis.
Committo,Ergo:Sum
Je ne vois pas encore tous les détails et conséquences impliqués mais je vois que mon idée d'une flexibilité maximale est bien la perspective de la solution présente.
Pour le reste je vais me mettre à examiner la doc.
merci, klaus++
Committo,Ergo:sum schrieb: