Re: problème avec cache-js

Si ça marche comme ça tant mieux, mais amha ça doit pas marcher partout car le hidden avec le id_xx clé primaire de l’objet édité c’est pas du tout un truc standard ni nécessaire. Il est présent sur les objets historiques pour des raisons historiques, mais il a aucune utilité (même si je vois que Fabrique le génère aussi…)

Proposition encore plus propre :

• dans le php tu construit un tableau des id_xx (les clés primaires des objets déclarés) que tu injecte dans le js dynamique (il changera si on installe/desinstalle un plugin avec un objet editorial)
• tu fais un js statique pour le plugin inserer_modele avec  une fonction qui prend en argument l’urk à modifier, le form target et la liste des id à chercher et qui cherche les id_xx dans le form et les ajoute à l'URL

Comme ça tu évites de dupliquer le même code et tu es plus robuste car tu risques pas de trouver un id_parent.

Pour la question des id_xx présent ou non en hidden, il faudrait en fait que le plugin insère ses propres hidden dans les formulaires sur lesquels il peut être activé, pour être certain des informations qu’il doit récupérer (et du coup ça éviterait d’avoir besoin d’une fonction js complexe).

Voire même le plugin peut inserer côté PHP en hidden l’URL de inserer_modeles à utiliser sur le formulaire en fonction des clés primaires dispos, et ça simplifie encore plus le JS qui sera encore plus stable

--
Cédric
Le 17 mars 2021 à 19:27 +0100, Maïeul Rouquette <[email protected]>, a écrit :
> Le 17/03/2021 à 16:18, Cerdic a écrit :
> > non non non, le problème ne vient pas de porte-plume.
> > Il permet de modifier le JS pour insérer des boutons et utiliser des
> > infos de config pour ce faire, et c’est le pourquoi du JS en squelette
> > modifiable via pipeline.
> >
> oui d'accord, mais moi je pensais que le porte plume générait une
> structure en data-truc et qu'ensuite on avait un code js fixe. Mais
> effectivement maintenant que j'ai vu concrètement, cela parait assez
> logique la manière dont cela marche
>
> > Mais bon là à partir du moment où on insère dedans du contenu qui change
> > à chaque URL comment est-ce qu’on peut supposer que ça marche ?
> > Et je redis, ton commit n’a fait que généraliser ce qu’il y avait avant,
> > en l’empirant certes, mais le problème était déjà là.
> >
> j'ai reverifier dans le code : non, avant le js était stable
>
> Quoi qu'il en soit j'ai fait une branche ici qui
>
> 1) permet d'avoir le but initial du commit, à savoir passer le
> id_objet_du_formulaire à la modalbox quelque soit l'objet en question
> 2) sans pour autant generer un js par id_objet_du_formulaire
>
> https://git.spip.net/spip-contrib-extensions/inserer_modeles/compare/master...tout_objet
>
> Marcimat et Rastapopoulos m'ont deja donné leur avis, et j'ai corrigé
> suivant leur idée. Mais une troisième relecture serait précieuse.
>
>
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip