Re: nomagic / no automagismes

Le 04/02/2020 à 06:38, JLuc a écrit :
> Le 03/02/2020 à 21:40, JLuc a écrit :
>> 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.

> 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.
> 
>> 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.
>>
>> JL
>>
> 
>