Charger systématiquement css et js sans tester les types de saisies #76

Closed
opened 2 months ago by nicod_ · 23 comments
nicod_ commented 2 months ago

Actuellement, les js et css utiles aux saisies (afficher_si, textarea/max_length, dates) sont insérées dans le <head> depuis le pipeline affichage_final.

Ça peut provoquer des bugs dans certains cas quand les tests ne passent pas (ex : ($p = strpos($flux, '<!--!inserer_saisie_editer-->')) !== false), et surtout ça ajoute des hits http sur certaines pages.

Je propose de simplifier tout ça et d'insérer systématiquement ces assets dans insert_head, sans tests, afin qu'ils soient pris en compte par le compresseur, pour optimiser le cache client.

Actuellement, les js et css utiles aux saisies (afficher_si, textarea/max_length, dates) sont insérées dans le `<head>` depuis le pipeline `affichage_final`. Ça peut provoquer des bugs dans certains cas quand les tests ne passent pas (ex : `($p = strpos($flux, '<!--!inserer_saisie_editer-->')) !== false`), et surtout ça ajoute des hits http sur certaines pages. Je propose de simplifier tout ça et d'insérer systématiquement ces assets dans `insert_head`, sans tests, afin qu'ils soient pris en compte par le compresseur, pour optimiser le cache client.
Collaborator

Je plussoie totalement. L'optimisation mal foutue est parfois pire que pas d'optimisation.

La seule question qui se pose c'est de savoir si cela va pas casser quelques styles puisqu'on s'intégrera pas avant le tout premier link.

Mais bon

  1. Si c'est un plugin, il suffirait d'avoir saisies en dépendance pour passer après les styles de saisies
  2. Si c'est un squelette il suffit de passer après #INSERT_HEAD
  3. Le css de saisies est pas si grand que cela
Je plussoie totalement. L'optimisation mal foutue est parfois pire que pas d'optimisation. La seule question qui se pose c'est de savoir si cela va pas casser quelques styles puisqu'on s'intégrera pas avant le tout premier link. Mais bon 1. Si c'est un plugin, il suffirait d'avoir saisies en dépendance pour passer après les styles de saisies 2. Si c'est un squelette il suffit de passer après #INSERT_HEAD 3. Le css de saisies est pas si grand que cela
Collaborator

Bonjour,

Peut-être rajouter une condition d'insertion : seulement s'il y a effectivement un formulaire avec le statut publié dans le site ?

Comme ça, si le plugin est seulement disponible dans le site, mais pas utilisé réellement, il n'alourdie pas les CSS et le JS.

Bonjour, Peut-être rajouter une condition d'insertion : seulement s'il y a effectivement un formulaire avec le statut publié dans le site ? Comme ça, si le plugin est seulement disponible dans le site, mais pas utilisé réellement, il n'alourdie pas les CSS et le JS.
Owner

Et de mémoire c'est moi qui avait fait ça fatigué d'avoir tous ces JS sur tout le site alors que les saisies ne sont - potentiellement - utilisées que sur une page ou deux là où il y a des formulaires (et dans mon cas c'était même jamais).

C'est sur que si ton site est principalement une app avec des formulaires et que tu as besoin des scripts presque partout, la méthode actuelle est pas optimale.

Mais a posteriori si ton site a juste un formulaire de contact et se trimbale la tripaille pour rien partout (vu que ce sont juste des champs simples qui ne necessitent pas de js), c'est dispendieux.

Je ne sais pas si il y a une solution idéale, peut-être il faut prévoir une option d'insertion dans la config du plugin pour permettre de choisir une option ou l'autre en fonction de son usage ?

Et de mémoire c'est moi qui avait fait ça fatigué d'avoir tous ces JS sur tout le site alors que les saisies ne sont - potentiellement - utilisées que sur une page ou deux là où il y a des formulaires (et dans mon cas c'était même jamais). C'est sur que si ton site est principalement une app avec des formulaires et que tu as besoin des scripts presque partout, la méthode actuelle est pas optimale. Mais a posteriori si ton site a juste un formulaire de contact et se trimbale la tripaille pour rien partout (vu que ce sont juste des champs simples qui ne necessitent pas de js), c'est dispendieux. Je ne sais pas si il y a une solution idéale, peut-être il faut prévoir une option d'insertion dans la config du plugin pour permettre de choisir une option ou l'autre en fonction de son usage ?
Collaborator

difficilement car tu peux avoir des formulaires qui utilisent saisies autres que formidable. Genre il y a des gens qui composent leurs formulaires à la main en utilisant saisies ;-)

Par contre c'est vrai que parfois saisies est chargé uniquement pour l'espace privé. On pourrait faire une config, comme pour barre d'outil, tablesorter et autre. Coché par défaut.

difficilement car tu peux avoir des formulaires qui utilisent saisies autres que formidable. Genre il y a des gens qui composent leurs formulaires à la main en utilisant saisies ;-) Par contre c'est vrai que parfois saisies est chargé uniquement pour l'espace privé. On pourrait faire une config, comme pour barre d'outil, tablesorter et autre. Coché par défaut.

Je suis d'accord avec @cerdic, dans la majorité des sites, ya 1 (ou 2, ou 4, ça change rien : très peu, pas sur toutes les pages du tout) formulaire, et 99% des pages n'en ont pas, et du coup autant pour le JS que pour les CSS, c'est dommage d'ajouter ça pour rien.

C'est plutôt ça il me semble : par défaut ça doit s'insérer uniquement si besoin. Et si option cochée, on l'insère partout tout le temps (genre "Si votre site contient beaucoup de formulaires, il est préférable blabla…").

Je suis d'accord avec @cerdic, dans la majorité des sites, ya 1 (ou 2, ou 4, ça change rien : très peu, pas sur toutes les pages du tout) formulaire, et 99% des pages n'en ont pas, et du coup autant pour le JS que pour les CSS, c'est dommage d'ajouter ça pour rien. C'est plutôt ça il me semble : par défaut ça doit s'insérer uniquement si besoin. Et si option cochée, on l'insère partout tout le temps (genre "Si votre site contient beaucoup de formulaires, il est préférable blabla…").
Poster

Sur ce commit :
71ffbc0fe1
suppression du pipeline affichage_final et déplacement dans insert_head.

Faire une config, ok, mais ça voudrait dire alors maintenir les deux pipelines en parallèle, sachant qu'ils font quasi la même chose (aux tests près).

Ou alors, une seule fonction saisies_generer_assets($tester_saisies = false) qui mutualiserait le code, appelée par insert_head et affichage_final ?

Sur ce commit : https://git.spip.net/spip-contrib-extensions/saisies/commit/71ffbc0fe11b7586fdcd29bda37e76ab4ecc7050 suppression du pipeline affichage_final et déplacement dans insert_head. Faire une config, ok, mais ça voudrait dire alors maintenir les deux pipelines en parallèle, sachant qu'ils font quasi la même chose (aux tests près). Ou alors, une seule fonction saisies_generer_assets($tester_saisies = false) qui mutualiserait le code, appelée par `insert_head` et `affichage_final` ?
Collaborator

oui mais alors un site qui aurait disons 2 pages sur 100 avec un formulaire, et qui n'aurait pas coché la case, il faut pouvoir lui inserer les scripts au cas par cas, page par page ? et dans ce cas rester avec affichage_final?

oui mais alors un site qui aurait disons 2 pages sur 100 avec un formulaire, et qui n'aurait pas coché la case, il faut pouvoir lui inserer les scripts au cas par cas, page par page ? et dans ce cas rester avec affichage_final?
Collaborator

Ou alors, une seule fonction saisies_generer_assets($tester_saisies = false) qui mutualiserait le code, appelée par insert_head et affichage_final ?

ce serait l'optimal oui sans doute. (et faudrait voir si du reste ca pourrait pas être utilisé pour le head du privé aussi du coup !)

> Ou alors, une seule fonction saisies_generer_assets($tester_saisies = false) qui mutualiserait le code, appelée par insert_head et affichage_final ? ce serait l'optimal oui sans doute. (et faudrait voir si du reste ca pourrait pas être utilisé pour le head du privé aussi du coup !)

oui mais alors un site qui aurait disons 2 pages sur 100 avec un formulaire, et qui n'aurait pas coché la case, il faut pouvoir lui inserer les scripts au cas par cas, page par page ? et dans ce cas rester avec affichage_final?

Ben c'est bien ce que j'ai dit non ?

Ça doit rester comme maintenant par défaut, donc insertion au besoin avec détection, bref vraiment le truc actuel. Et si option cochée ça ne fait pas ces tests du tout et donc ça sort direct du pipeline, mais par contre ça les insère dans un autre.

Par contre je vois mal comment ça pourrait être mutualisé car c'est pas du tout fait pareil : dans affichage_final au cas par cas, on insère ça ensemble, alors que sinon quand c'est pour le site entier, pour que ce soit optimisé, on insère les JS d'un côté, et les CSS de l'autre, dans deux pipelines différents. Donc c'est juste que suivant la config, on insère pas depuis les mêmes pipelines.

> oui mais alors un site qui aurait disons 2 pages sur 100 avec un formulaire, et qui n'aurait pas coché la case, il faut pouvoir lui inserer les scripts au cas par cas, page par page ? et dans ce cas rester avec affichage_final? Ben c'est bien ce que j'ai dit non ? Ça doit rester comme maintenant par défaut, donc insertion *au besoin* avec détection, bref vraiment le truc actuel. Et si option cochée ça ne fait pas ces tests du tout et donc ça sort direct du pipeline, mais par contre ça les insère dans un autre. Par contre je vois mal comment ça pourrait être mutualisé car c'est pas du tout fait pareil : dans affichage_final au cas par cas, on insère ça ensemble, alors que sinon quand c'est pour le site entier, pour que ce soit optimisé, on insère les JS d'un côté, et les CSS de l'autre, dans deux pipelines différents. Donc c'est juste que suivant la config, on insère pas depuis les mêmes pipelines.
Collaborator

@nicod plutot qu'affichage_final il faudrait utiliser formulaire_fond (mais je ne sais plus à partir de quand cela existe. 3.0 ?). Cela permettrait aussi de gerer ton cas de forme chargé en ajax.

@nicod plutot qu'affichage_final il faudrait utiliser formulaire_fond (mais je ne sais plus à partir de quand cela existe. 3.0 ?). Cela permettrait aussi de gerer ton cas de forme chargé en ajax.
Poster

Il n'y a pas de formulaire de config pour les saisies, est ce qu'on en crée un juste pour ça ?
Ou est ce qu'on joue sur une constante à déclarer selon ses besoins ?
Genre _SAISIES_ASSETS_GLOBAL ?

Il n'y a pas de formulaire de config pour les saisies, est ce qu'on en crée un juste pour ça ? Ou est ce qu'on joue sur une constante à déclarer selon ses besoins ? Genre `_SAISIES_ASSETS_GLOBAL` ?
Collaborator
  • pour le porteplume, c'est une config
  • pour tablesorter, c'est aussi une config

Donc j'aurais tendance à dire de suivre la même voie...

- pour le porteplume, c'est une config - pour tablesorter, c'est aussi une config Donc j'aurais tendance à dire de suivre la même voie...
Poster

formulaire_fond ne permet pas d'insérer dans le head...

formulaire_fond ne permet pas d'insérer dans le head...
Collaborator

formulaire_fond ne permet pas d'insérer dans le head...

en a-t-on besoin ?

> formulaire_fond ne permet pas d'insérer dans le head... en a-t-on besoin ?
Poster

C'est plus propre d'insérer dans le head oui, et pourquoi passer par formulaire_fond ? ça apporterait quoi ?

C'est plus propre d'insérer dans le head oui, et pourquoi passer par formulaire_fond ? ça apporterait quoi ?
Poster

Nouvelle version, avec une configuration (désactivée par défaut) :
8c4dfe9497

Nouvelle version, avec une configuration (désactivée par défaut) : https://git.spip.net/spip-contrib-extensions/saisies/commit/8c4dfe9497a16d438dde0d3c2737f8ec92c781e7
Collaborator
  1. Ne pas parser toute la page à chaque hit
  2. Si jamais ton formulaire est chargé en AJAX, ne pas avoir le problème que tu connais

Après, je sais pas si le temps qu'onm gagne côté PHP on le perd pas côté ordre de chargement...

1. Ne pas parser toute la page à chaque hit 2. Si jamais ton formulaire est chargé en AJAX, ne pas avoir le problème que tu connais Après, je sais pas si le temps qu'onm gagne côté PHP on le perd pas côté ordre de chargement...
Poster

Ok pour formulaire_fond en fait, après réflexion.
Tu modifies ou je le fais ?

Il faut juste renommer le pipeline affiche_final et utiliser $flux['data'], à priori.

Ok pour formulaire_fond en fait, après réflexion. Tu modifies ou je le fais ? Il faut juste renommer le pipeline affiche_final et utiliser $flux['data'], à priori.
Collaborator

je suis occupé, donc je te laisse faire. Mais n'oublie pas de puller.

je suis occupé, donc je te laisse faire. Mais n'oublie pas de puller.
Collaborator

attention si formulaire_fond, il faut verifier que cela le fait pas côté privé.

attention si formulaire_fond, il faut verifier que cela le fait pas côté privé.

Je comprends pas votre truc avec formulaire_fond, où on a que le contexte du formulaire en quesiton, donc impossible de savoir si le JS et le CSS ont pas déjà été inséré autre part dans la page, non ? Le but c'est bien de l'insérer qu'une unique fois dans toute la page, pas 12 fois la même chose, si ya plusieurs formulaires.

Je comprends pas votre truc avec formulaire_fond, où on a que le contexte du formulaire en quesiton, donc impossible de savoir si le JS et le CSS ont pas déjà été inséré *autre part dans la page*, non ? Le but c'est bien de l'insérer qu'une unique fois dans toute la page, pas 12 fois la même chose, si ya plusieurs formulaires.
Collaborator

tu met un flag en static

tu met un flag en static
maieul referenced this issue from a commit 1 month ago
maieul closed this issue 1 month ago
Collaborator

C'est donc fusionné. On laisse tomber cette affaire de formulaire_fond, pour l'instant, car cela compliquerait le code pour pas grand chose de gerer avec les static pour s'assurer que chacun asset individuel ne sera présent qu'une seul fois.

Pas de release pour l'instant, on le fera en même temps que #7 et #72

C'est donc fusionné. On laisse tomber cette affaire de formulaire_fond, pour l'instant, car cela compliquerait le code pour pas grand chose de gerer avec les static pour s'assurer que chacun asset individuel ne sera présent qu'une seul fois. Pas de release pour l'instant, on le fera en même temps que #7 et #72
Sign in to join this conversation.
No Milestone
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.