Discussion :

[Invité]

Bonjour,

Je travaille sur un filtre symfony qui a pour objectif de faciliter l'intégration d'un script css/javascript.

Celui-ci ne doit s'activer que si un certain tag est trouvé dans le code html de la vue.
- Si ce tag est trouvé, on ajoute un fichier javascript et un fichier css ( si possible via l'objet $response )
- Si le tag n'est pas trouvé, rien ne se passe.

Mon problème actuel c'est que j'ai l'impression qu'il est impossible d'ajouter les fichiers css/js après avoir récupérer le contenu de la page web.

Actuellement j'ai un script qui a la forme suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
public function execute($filterChain)
{
  $response = $this->context->getResponse();
 
  // Dans la situation actuelle, j'ajoute les fichiers css/js dans tous les cas, car je n'arrive pas à faire autrement
  $response->addJavascript('/sfSyntaxHighlighterPlugin/js/shCore');
  $response->addStylesheet('/sfSyntaxHighlighterPlugin/css/shCore');
 
  // A partir de maintenant on peut avoir accès au code html
  // Mais les méthodes sur $response ne fonctionnent plus
  $filterChain->execute();
  $content= $response->getContent();
 
  if ($this->check($content)) 
  {
    .... 
    $response->setContent($content); 
}
 
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
rendering: ~
 
remember_me:
  class: sfGuardRememberMeFilter
 
security:  ~
 
sf_syntax_highlighter_plugin:
    class: sfSMonFiltreFilter
 
cache:     ~
execution: ~

Comme vous pouvez le voir, dans cette situation j'inclus obligatoirement les fichier css/js même si il n'ont pas de raison d'être inclus.
Auriez-vous une solution/astuce pour me permettre d'optimiser ce comportement ?

Merci pour votre aide !

[Crysfall]

Hello,

A partir du moment où tu appeles

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$filterChain->execute();

Les filtres poursuivent leur exécution, tu quittes donc ton filtre pour le suivant, ton code qui précède cette instruction ne sera jamais exécuté.

++

[Michel Rotta]

Si on reste dans le cadre stricte de l'utilisation d'un filtre. Le filtre s'exécute en deux fois : avant le $filterChain->execute() et après, ce que tu as bien compris.

La difficulté viens qu'après le execute() et dans l'emplacement normal des filtres, la page est déjà générée. Si tu veux y insérer du javascript ou/et du css, il faut aller modifier le fichier, la page générer par des fonctions de substitutions de php. Avec le risque, suivant la configuration, qu'une partie de la page ait été déjà envoyée à l'utilisateur, et soit donc non modifiable. Il faut alors s'assurer que la page sera conservée en cache jusqu'à la fin de la chaine de filtres, ce qui risque de ralentir (en apparence) le site pour un utilisateur.


Je n'ai pas détaillé pour la raison que je pense que cette méthode est inutilement compliquée. Dans la mesure où, dans ton template, tu sais que tu vas avoir besoin de ce javascript et de ce css, vu que tu y place la balise, il me semble plus simple d'ajouter les fichiers javascript et css directement depuis le template, tous simplement. Moi c'est ainsi que je le mettrais en œuvre.

[Invité]

Je n'ai pas détaillé pour la raison que je pense que cette méthode est inutilement compliquée. Dans la mesure où, dans ton template, tu sais que tu vas avoir besoin de ce javascript et de ce css, vu que tu y place la balise, il me semble plus simple d'ajouter les fichiers javascript et css directement depuis le template, tous simplement. Moi c'est ainsi que je le mettrais en œuvre.

Je vais surement m'orienter vers cette solution car dans mon cas c'est possible, mais ça reste tout de même du bidouillage ( surtout moins optimisé que ce que j'aurais voulu ).

Je vais être plus précis dans le fonctionnel de mon filtre pour que vous compreniez mieux.

J'ai par exemple une page article avec plusieurs champs clob libre. Mon filtre ( qui est un plugin SF en fait ) permet, si il trouve un tag du style dans la page, d'inclure des fichiers css/javascript et de lancer les fonctions nécessaire pour transformer cette balise en un bloc SyntaxHighlighter.

L'inclusion de ce script étant assez lourde, j'aurais préféré qu'il ne soit inclus que si il est réellement utile ( donc peut être 1x / 10 sur ma vue "articleDetail" ).

La solution alternative que j'ai est de faire un helper qui va tester mes variables libres et inclure les codes js/css si nécessaire. Mais cela devra être fait pour toutes les variables susceptibles de contenir une telle balise, alors qu'avec un filtre j'aurais pensé que cela puisse être automatisé.

[Michel Rotta]

Je ne suis pas sur d'exactement comprendre, je vais donc reformuler.

Tu as, dans certaines pages, des champs de type cblog qui, pour pouvoir être saisi confortablement par l'utilisateur, doivent être renforcés par un javascript. Ces champs sont tous de type cblob.

Mes questions et interrogations:

• est-ce qu'un champ de typ cblob doit toujours être assisté pour le code javascript ?
• que faire si, dans l'avenir, un cblob qui contiendrait d'autre données ne devra pas être supporté par cette fonction javascript ?
• Un même formulaire (issu d'un template) doit toujours avoir le javascript activé quant il s'affiche (vu qu'il y a un cblob dans les champs du formulaire).

Si les réponses sont : oui, oups, oui alors je pense que la meilleur solution est de préciser, dans chaque template, les javascripts particulier à utiliser. C'est la plus rapide et la plus sur. Mettre un filtre en place risque, à terme, de nous jouer des tours. De plus, dans 90% des cas, le code source de la page devra être examiné pour rien par le filtre vu que la page n'a pas à ce voir modifiée. D'où des pénalités en terme de temps de génération de la page supplémentaire et non nécessaire.

[Invité]

Voilà mes réponses :

Tu as, dans certaines pages, des champs de type cblog qui, pour pouvoir être saisi confortablement par l'utilisateur, doivent être renforcés par un javascript. Ces champs sont tous de type cblob.

Oui, ce sont des champs wysiwyg qui peuvent contenir des balises bbcode, dont certaines doivent être renforcées par du jvs.

est-ce qu'un champ de typ cblob doit toujours être assisté pour le code javascript ?

Non, un article du blog peut contenir une balise si il parle de programmation, mais il peut tout aussi bien parler d'un autre sujet ou ne pas contenir de snippet.

que faire si, dans l'avenir, un cblob qui contiendrait d'autre données ne devra pas être supporté par cette fonction javascript ?

Si le champs clob ne contient pas le tag , il n'est pas nécessaire d'inclure le javascript (qui en gros représente le coeur du plugin de syntaxHighlighter + le thème). Je ne pense pas que cette interrogation soit pertinente.

Un même formulaire (issu d'un template) doit toujours avoir le javascript activé quant il s'affiche (vu qu'il y a un cblob dans les champs du formulaire).

C'est là que l'optimisation serait intéressante : je souhaiterais que le javascript du plugin ne soit intégré que si il est nécessaire (présence en gros de dans la vue ).
Donc sur une même vue, je ne souhaiterais pas que le javascript soit inclus à chaque fois, mais uniquement lorsque c'est nécessaire.

En utilisant le principe de filtre, on a pas à se poser de question : est-ce que sur ce template (vue) je risque d'avoir le tag qui doit déclencher l'inclusion des javascripts. Pour le développeur qui utiliserait ce plugin, c'est plus simple, il n'a pas de code à ajouter dans ses templates.

Si les réponses sont : oui, oups, oui alors je pense que la meilleur solution est de préciser, dans chaque template, les javascripts particulier à utiliser. C'est la plus rapide et la plus sur. Mettre un filtre en place risque, à terme, de nous jouer des tours.

Tout à fait d'accord, cela demande un effort supplémentaire au développeur c'est tout ( un dieu sait que les développeurs sont des flemmards ^^ )

De plus, dans 90% des cas, le code source de la page devra être examiné pour rien par le filtre vu que la page n'a pas à ce voir modifiée. D'où des pénalités en terme de temps de génération de la page supplémentaire et non nécessaire.

Là je suis tout à fait d'accord, en y réfléchissant de nouveau, c'est vrai qu'un filter c'est un peu sortir un tank pour écraser une mouche. D'un côté je gagne en temps de chargement de la page, d'un autre je gagne en temps de génération côté serveur ( sans oublier que le jvs une fois chargé reste en cache )

Mais je pense à autre chose : mon filtre ne se contente pas d'inclure le jvs/css (@see sfSyntaxHighlighterFilter), il effectue d'autres transformations comme remplacer les tags bbcode ( ) par leur équivalent html ( => <pre class="......"></pre> ). Donc il devra être dans tous les cas être appelé sur toutes les pages, de tous les modules ( avec la possibilité d'inclure la config au niveau du module et non de l'application, pour réduire la charge serveur ).

Bref un problème compliqué sans solution miracle, mais un compromis difficile à trouver entre optimisation client, optimisation serveur et optimisation développement.