Je suis surpris par le fonctionnement des inclusions ajax.
Lorsqu'on les inclue, elles bénéficient du contexte passé en argument de l'inclusion :
les arguments explicites + l'environnement du contexte via 'env'.
Soit.
La doc recommande aussi de toujours passer 'env'. Soit.
Souvent ensuite le rechargement ajax se fait avec un href basé sur #SELF
(cf https://www.spip.net/fr_article3753.html ou https://programmer.spip.net/Liens-AJAX)
mais potentiellement les variables de la query de #SELF sont totalement différentes
de celles du contexte incluant la noisette ajax : noms de variables différents,
ou valeurs différentes.
Par exemple, sur une page article on peut avoir une noisette ajax qui présente la météo
du jour dont le n° dans l'année est indiqué par un champ extra de cet article.
(juste un exemple...)
Ce qui me surprend, c'est que lors du chargement ajax après clic, la noisette reçoit en contexte
- à la fois (prioritairement) les variables d'url de #SELF, complétées des éventuels parametre_url,
- ET les variables du contexte d'inclusion initial de la noisette
telles qu'elles se présentent lors du calcul de la page initiale incluant la noisette
(du moins celles qui ne sont pas écrasées par les variables du #SELF).
D'une certaine manière l'url du lien ajax ne sert QUE pour ses arguments d'url
puisque les squelettes de cette page, qui calculent et préparent le contexte d'appel de l'inclusion ajax
ne sont pas mis à contribution lors du clic d'un lien ajax.
Ça ne doit pas poser souvent problème,
mais ça doit en poser dans les cas où la valeur d'un contexte est calculée...
et où il va donc falloir faire autrement pour que ces calculs soient refaits
et ne soient pas écrasés au clic ajax.
Il n’y a pas de magie, et c’est donc à toi concepteur de squelettes de faire en sorte que ça marche dans les cas tordus, par exemple en faisant ton calcul complexe dans la noisette ajax elle-meme, en fonction des arguments de l’url+env.
Et comme tu dis, c’est un principe de fonctionnement qui marche spontanément dans 90% des cas, les 10% restant seraient beaucoup trop dispendieux à obtenir pour que ça vaille la peine, on compte donc sur un peu de bonne volonté de celui qui fait les squelettes pour les gérer.
Parfois tout de même, le codeur innocent se prend les pieds dans les ficelles.
Par exemple je me retrouvais avec un id_document parasite au sortir d'une popin d'édition d'un document
appelé dans la page d'un autre objet.
La raison : $res['redirect'] = parametre_url($retour, $id_table_objet, $id);
à la fin de formulaires_editer_objet_traiter
Un autre jour, c'était #SELF qui ajoute les _POST aux arguments de l'url "réelle".
J'avais du créer une balise doublon mais sans cet ajout qui gênait à un endroit.
Et bien avant, je me heurtais à ce fonctionnement particulier de form_hidden https://core.spip.net/issues/3769 que je ne saurais plus décrire aujourd'hui
mais mon code garde un doublon dépouillé de ce comportement parfois dérangeant.
À chaque fois c'est très déconcertant.
Et ça semble toujours en relation avec des globales.
Parfois tout de même, le codeur innocent se prend les pieds dans les ficelles
... des automagismes.
Les autres exemples donnés ne concernent pas l'exemple ajax à l'origine de ce fil.
Je me demande si d'autres personnes sont confrontées occasionnellement à ces difficultés,
auquel cas ça serait pas inutile de créer un plugin "nomagic" qui proposerait une copie des fonctions
et balises qui générent cette magie, préfixées par nomagic_ et SANS leur ajouts automagiques,
que le dev aurait loisir d'employer lorsque son plugin ou squelette ne supporte pas les automagismes de spip.
Parfois tout de même, le codeur innocent se prend les pieds dans les ficelles
... des automagismes.
Je remarque que dans tous les cas évoqués : environnement de rechargement ajax
et autres exemples cités, le contexte d'environnement est automagiquement augmenté
par des variables de l'url.
Dans certains cas, ces variables introduites par effet de bord
peuvent ne pas du tout concerner la sémantique de cette noisette.
- Cela multiplie inutilement les caches.
Par exemple la noisette reloadée par ajax génère un cache qui ne servira plus jamais
car les appels suivants de la page ne lui fourniront pas ces variables superfétatoires.
- En cas d'interférence avec les arguments désirés, cela peut perturber le fonctionnement.
Un de mes sites utilisant cachelab est peut être plus sensible à ces particularités
puisque les caches ne sont pas recalculés à toute modification de la BDD.
L'idée d'un plugin nomagic n'st pas de supprimer toute magie
(puisque celle ci est le plus souvent bienvenue)
mais de fournir des fonctions sans magie, préfixées par nomagic_ ,
utilisables au besoin par les pipelines, codes de traitements de formulaires
et autres devs maisons pour les besoins d'un plugin.
Indépendamment, je trouverais salutaire de documenter cela dans le code
par exemple par un simple commentaire // Automagisme
et mieux, permettre de débrayer localement débrayable.
Par exemple avec une variable globale qui évite de devoir changer les signatures des fonctions.
if ($GLOBALS['spip_automagisme']) {
// ici le truc de magie
}
À la fois ça permet de débrayer (dans le code d'appel) et ça signale ces tricks.
Parfois tout de même, le codeur innocent se prend les pieds dans les ficelles
… des automagismes.
Je remarque que dans tous les cas évoqués : environnement de rechargement ajax
et autres exemples cités, le contexte d’environnement est automagiquement augmenté
par des variables de l’url.
Vécu Chaque fois je revois la copie et tente de simplifier (et spécifier quand il y a risque de télescopage)
Dans certains cas, ces variables introduites par effet de bord
peuvent ne pas du tout concerner la sémantique de cette noisette.
Cela multiplie inutilement les caches.
Par exemple la noisette reloadée par ajax génère un cache qui ne servira plus jamais
car les appels suivants de la page ne lui fourniront pas ces variables superfétatoires.
Très bon point.
En cas d’interférence avec les arguments désirés, cela peut perturber le fonctionnement.
Un de mes sites utilisant cachelab est peut être plus sensible à ces particularités
puisque les caches ne sont pas recalculés à toute modification de la BDD.
L’idée d’un plugin nomagic n’st pas de supprimer toute magie
(puisque celle ci est le plus souvent bienvenue)
mais de fournir des fonctions sans magie, préfixées par nomagic_ ,
utilisables au besoin par les pipelines, codes de traitements de formulaires
et autres devs maisons pour les besoins d’un plugin.
Chaque fois je revois la copie et tente de simplifier (et spécifier quand il y a risque de télescopage)