[spip-dev] RE: [Spip] Par hasard, nouvelle formule

Franck,

La formule proposée fonctionne a priori avec toutes les versions de MySQL
qui supportaient déjà l'autre formule. UNIX_TIMESTAMP() n'est pas spécifique
à Unix, il s'agit juste d'une représentation du temps dans laquelle une date
est exprimée comme le nombre de secondes ou de millisecondes écoulées depuis
le 1er janvier 1971 (~ depuis l'invention d'Unix). En outre, l'ancienne
formule faisait déjà appel à UNIX_TIMESTAMP().

inc-calcul-squel.php3, ligne 492, remplacer par :
$req_select[] = "COS($table.$id_objet * UNIX_TIMESTAMP()) * 32767 AS alea";

Cordialement,

Francis PALLINI
ECILIA - Ingénieur INSA Lyon
Tél : 04.78.68.46.23
Fax : 04.37.43.69.01

-----Message d'origine-----

Messieurs,

Il y a des dames aussi !

Je propose de remplacer la ligne 492 de inc-calcul-squel.php3 (version
1.7.2)
de la manière suivante :
< $req_select = "MOD($table.$id_objet * UNIX_TIMESTAMP(), 32767) &
UNIX_TIMESTAMP() AS alea";
> $req_select = "COS($table.$id_objet * UNIX_TIMESTAMP()) * 32767 AS
alea";

Oui, pourquoi pas en effet. Ce qui m'amuse c'est qu'on n'ait pas choisi
d'utiliser RAND() ; je ne retrouve pas pourquoi.

-- Fil

Sauf erreur, parce que RAND() n'existe pas les anciennes versions de mySQL.

ARNO*

> Oui, pourquoi pas en effet. Ce qui m'amuse c'est qu'on n'ait pas choisi
> d'utiliser RAND() ; je ne retrouve pas pourquoi.
>

Sauf erreur, parce que RAND() n'existe pas les anciennes versions de
mySQL.

Oui, c'était ça.

Amicalement

Antoine.

Salut,
petit detail de fonctionnement du nouveau compilo :
J'ai fait tourner le diaporama du Bloog et, surprise, l'image restait
toujours la meme ...
en fait, dans la boucle document, {debut_img,1} etait calculé et mis en
cache.

le systeme d'aiguillage du Bloog (que j'ai repris dans mes squelettes, merci
M. BoOz !) choisit le squelette article.php3 appelle toujours article.html
qui contient :

<INCLURE(aiguillage_article.php3){id_article}>

Il faut lui passer debut_img pour qu'il en tienne compte dans le contexte :
<INCLURE(aiguillage_article.php3){id_article}{debut_img}>

Ce comportement me parait très sain (on met en cache les inclusions en
fonction d'un contexte donné explicitement) mais il faut y penser ...

A contrario, en regardant le cache, j'ai constaté qu'il me generait bien un
fichier pour chaque valeur de debut_img passée pour article, ce qui est
normal, mais dans ce cas précis ne m'interesse pas (les fichiers sont
identiques puisque debut_img n'intervient pas à ce niveau mais uniquement
dans le cache inclus).
Est-ce qu'on ne pourrait pas prévoir un systeme pour basculer vers un
passage explicite du contexte (idéalement uniquement pour les variables
"non-spip") ou un système d'exclusion ?
je pensais à un truc du genre :
<?php

$fond = "_template/__article";
$delais = 3600;
$contexte['get']=... (type array ? quelle valeur pour aucun ? null pour
toutes ?)
$contexte['post']=...
include ("inc-public.php3");

?>

C'est juste une idée comme ca, c'est peut etre bete, je ne sais pas, mais ca
doit pouvoir se coder sans perturber le fonctionnement actuel et, pour ceux
qui ont plusieurs niveaux d'inclusion, et du php qui utilise des variables
passées en GET ou POST, ca peut etre interessant, non ?
Ca doit pouvoir se faire en passsant $contexte à calculer_contexte et en
n'en tenant compte que si il est donné.
Bon, ok, en v72 ...
En attendant, si j'ai bien compris, il faut nommer ses variables var_
quelquechose si on ne veut pas qu'elles soient prises en compte à la
génération du cache, c'est bien ca ?

@++

> > Oui, pourquoi pas en effet. Ce qui m'amuse c'est qu'on n'ait pas choisi
> > d'utiliser RAND() ; je ne retrouve pas pourquoi.
> Sauf erreur, parce que RAND() n'existe pas les anciennes versions de
> mySQL.
Oui, c'était ça.

OK. J'envoie une modif qui teste si RAND() fonctionne et sinon se
rabat sur la vieille formule.

-- Fil