[spip-dev] variables supplémentaires

fil · Janvier 28, 2002, 11:35

Coucou,

j'aimerais qu'on propose des variables "non cachées", je m'explique : si
j'utilise la variable "coucou" dans mes squelettes (avec du php pour
l'analyser), l'URL est de la forme

http://wwwwwwwwww/spip/article.php3?id_article=9&coucou=8

et le cache est reclaculé pour chaque valeur de coucou. Ce serait pas mal
que, pour une certaine classe de variables, le cache utilisé soit celui qui
correspond à http://wwwwwwwwww/spip/article.php3?id_article=9

(On a fait un truc équivalent, c'es-t-à-dire un traitement spécial, avec les
variables debut_xxx)

Je vous propose var_xxx comme classe de variables éliminées du request_uri à
partir duquel on détermine le nom du cache. Pas d'inconvénient ?

Ca donnerait :
http://wwwwwwwwww/spip/article.php3?id_article=9&var_coucou=8

Nom du cache : x/%2Farticle.php3%3Fid_article%3D9
au lieu de : x/%2Farticle.php3%3Fid_article%3D9%26coucou%3D8

-- Fil

Nicolas_Hoizey2 · Janvier 28, 2002, 11:38

j'aimerais qu'on propose des variables "non cachées"

+1

ea4038dd8d8a365bed58 · Janvier 28, 2002, 2:15

Si, risque de perdre des choses en route. Par exemple interface de forums paramétrables, débuts de listes, chaque fois qu'il y a une variable passée "discrètement" dans certains forums... Si on passe des variables différentes, il y a des chances qu'on veuille un affichage de page différent. Sans compter ceux qui hackent SPIP, et vont donc ajouter des variables en contexte pour obtenir certains résultats; si on écrase cela dans le même fichier cache, ça pose problème.

En fait, je ne vois pas bien l'intérêt des variables "non cachées". Si on passe des variables, c'est bien pour obtenir des résultats différents, non?

ARNO*

fil · Janvier 28, 2002, 2:24

@ Arno* <arno@scarabee.com> :

En fait, je ne vois pas bien l'intérêt des variables "non cachées".
Si on passe des variables, c'est bien pour obtenir des résultats
différents, non?

exemples :

- je veux faire un système de pagination (cf. mon mail précédent sur le
sujet). La page cachée doit contenir tout le texte, et répondra des choses
différentes en fonction de la variable ?var_page=x passée en paramètre.

Bien, avec le système actuel, si je fais "recalculer" sur ma page 1, la page
2 n'est pas recalculée, puisqu'elle est dans une autre fichier cache ! La
var_page indique une autre vue, mais du même objet (ce n'est pas tout à fait
la même chose pour "imprimer_article", de mon point de vue), qui POURRAIT
donc être dans le même cache.

- s'inscrire à la liste machin. var_email ne doit pas apparaître dans le
cache. S'il apparaît, d'ailleurs, il faut recalculer toute la page pour
chaque email, ce qui 1) ralentit : fait perdre le bénéfice du cache ;
2) remplit inutilement le dossier cache/ ; 3) laisse des infos de "privacy"
sans que ce soit nécessaire.

Pour résoudre cette contradiction il faudrait tout coder en formulaires
POST, ce qui n'est pas franchement pratique dans certaines situations (la
pagination en POST, ça serait vraiment naze !)

- Pour intégrer un script extérieur dans spip, je vais avoir tendance à le
coller dans un squelette. Si ce script se GET des variables, les squelettes
correspondant à la même page mais à des variables différentes pour ce script
se multiplieront d'autant. Inutile, lent, et pour tout dire lamentable.

- enfin, je bosse sur un formulaire "écrire à l'auteur", et là je sens que
ça aurait un gros bénéfice. Mais tant que c'est pas fini, je ne suis pas
sûr...

à plus.

-- Fil

fil · Janvier 28, 2002, 2:43

@ Arno* <arno@scarabee.com> :

Si, risque de perdre des choses en route. Par exemple interface de
forums paramétrables, débuts de listes, chaque fois qu'il y a une
variable passée "discrètement" dans certains forums... Si on passe
des variables différentes, il y a des chances qu'on veuille un
affichage de page différent. Sans compter ceux qui hackent SPIP, et
vont donc ajouter des variables en contexte pour obtenir certains
résultats; si on écrase cela dans le même fichier cache, ça pose
problème.

Euh, attends, je crois qu'on ne s'est pas compris : seules les variables
dénommées var_xxxx seraient zappées ! Il ne s'agit pas de "couper" l'URI
après elles, mais de les en extirper proprement.

Il suffirait, au même endroit où l'on zappe [?&]recalcul=oui.*, de zapper
les var_xxx comme suit (de tête) :

    if (ereg("[?&]var_\w+(=[^&]+)?&?", $uri, $match)) {
        $pos = $strpos($match[0], $uri);
        $len = strlen($match[0]);
        $uri = substr($uri, 0, $pos-1) . $match[1]
            . substr($uri, $pos -1 + $len);
    }

et c'est tout.

-- Fil

63438612493668b99328 · Janvier 28, 2002, 2:49

- Pour intégrer un script extérieur dans spip, je vais avoir tendance à
le coller dans un squelette. Si ce script se GET des variables, les
squelettes correspondant à la même page mais à des variables
différentes pour ce script se multiplieront d'autant. Inutile, lent, et
pour tout dire lamentable.

Oui, mais faut hacker le script extérieur pour changer le nom des
variables (à moins qu'elles comment déjà par var_).

- enfin, je bosse sur un formulaire "écrire à l'auteur", et là je sens
que ça aurait un gros bénéfice.

Il me semble plus raisonnable de le faire en POST, ne serait-ce que pour
éviter les reloads qui envoient dix exemplaires du texte dans la boîte
du pauvre destinataire (surtout si c'est du HTML, mais j'espère que tu
n'as pas l'intention d'envoyer l'article en HTML ?).

Je repropose un peu ce que je pense du format "correct" des formulaires
de l'espace public :

- envoi en POST
- la page récupère les infos, fait les traitements nécessaires, mais
n'affiche soit rien soit juste un message de confirmation de prise
en compte (pétitions, etc)
- redirection ou lien vers l'URL finale (en GET donc), envoyée en
paramètre du POST initial

C'est déjà ce qui est fait pour les forums.

Bon, je comprends l'intérêt du truc, ceci dit.

fil · Janvier 28, 2002, 3:07

@ Antoine Pitrou <antoine@rezo.net> :

> différentes pour ce script se multiplieront d'autant. Inutile, lent, et
> pour tout dire lamentable.
Oui, mais faut hacker le script extérieur pour changer le nom des
variables (à moins qu'elles comment déjà par var_).

Oui, c'est sûr. Mais moindre mal qu'actuellement.

> - enfin, je bosse sur un formulaire "écrire à l'auteur", et là je sens
> que ça aurait un gros bénéfice.

Il me semble plus raisonnable de le faire en POST, ne serait-ce que pour
éviter les reloads qui envoient dix exemplaires du texte dans la boîte
du pauvre destinataire (surtout si c'est du HTML, mais j'espère que tu
n'as pas l'intention d'envoyer l'article en HTML ?).

C'est une question ?

Je repropose un peu ce que je pense du format "correct" des formulaires
de l'espace public :

- envoi en POST
- la page récupère les infos, fait les traitements nécessaires, mais
n'affiche soit rien soit juste un message de confirmation de prise
en compte (pétitions, etc)
- redirection ou lien vers l'URL finale (en GET donc), envoyée en
paramètre du POST initial

C'est déjà ce qui est fait pour les forums.

Dans ce cas précis, en effet il vaut mieux avoir ce schéma. Est-ce qu'on
centralise les renvois sur un spip_formulaires.php3 unique - et on agit en
fonction des variables passées ? Ou est-ce qu'il vaut mieux développer un
spip_renvoi_xxx par type de formulaire ?

-- Fil

fil · Janvier 28, 2002, 8:43

Il suffirait, au même endroit où l'on zappe [?&]recalcul=oui.*, de zapper
les var_xxx comme suit (de tête) :

Voilà qui est fait : modif. dans inc-public.php3 (version SPIP-1.4a4)
On extirpe var_xxx=machin (à condition que ça commence par var_) du calcul
du nom du fichier cache.

-- Fil

fil · Janvier 28, 2002, 8:46

Voilà qui est fait : modif. dans inc-public.php3 (version SPIP-1.4a4)
On extirpe var_xxx=machin (à condition que ça commence par var_) du calcul
du nom du fichier cache.

PS: c'est fait proprement, je vérifie les bouts qui dépassent (? ou &
devant, & derrière) et je recompose ce qu'il faut.

-- Fil

fil · Janvier 28, 2002, 9:00

@ Fil :

> - enfin, je bosse sur un formulaire "écrire à l'auteur", et là je sens
> que ça aurait un gros bénéfice.

@ Antoine Pitrou <antoine@rezo.net> :

Il me semble plus raisonnable de le faire en POST, ne serait-ce que pour
éviter les reloads qui envoient dix exemplaires du texte dans la boîte
du pauvre destinataire (surtout si c'est du HTML, mais j'espère que tu
n'as pas l'intention d'envoyer l'article en HTML ?).

Je repropose un peu ce que je pense du format "correct" des formulaires
de l'espace public :

- envoi en POST
- la page récupère les infos, fait les traitements nécessaires, mais
n'affiche soit rien soit juste un message de confirmation de prise
en compte (pétitions, etc)
- redirection ou lien vers l'URL finale (en GET donc), envoyée en
paramètre du POST initial

C'est déjà ce qui est fait pour les forums.

Bon, allons-y : j'ai créé le tag #FORMULAIRE_ECRIRE_AUTEUR, qui crée tout ce
qu'il faut dans le squelette etc de manière à appeler la fonction
ecrire_auteur($id_auteur) dans inc-formulaires.php3 ; que doit faire cette
fonction ?

- S'il n'y a pas d'envoi, afficher un formulaire

- Mais ensuite, où doit pointer ce formulaire ? Sur forum.php3 (que je
patcherais), sur ecrire.php3 (qu'il faudrait créer avec en plus un nouveau
squelette ecrire.html), ou sur un ecrire.php3 qui envoit le mail et renvoit
vers l'URL d'origine ? (Je précise que je souhaite que l'émetteur du mail
ait une étape de prévisualisation, histoire de ne pas avoir trop de
déchet..)

-- Fil