Re: nomagic / no automagismes
Gildas Cotomale <[email protected]>
| Newsgroups | gmane.comp.web.spip.devel |
|---|---|
| Message-ID | <CAKRmq4Ar80TOmFSg3yMs89=M5iqrije=a+ATF7UvTVOdcpregA@mail.gmail.com> |
Le mer. 5 févr. 2020 09:12, JLuc a écrit :
> 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.
>
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.
>
Ce serait bienvenue
> 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
> >>
>