14/02/2012, 16:04:46
J'aime particulièrement l'idée de Youpi qui vient combler les défauts des modules qui génèrent parfois beaucoup de script (et en double par dessus le marché) en remplaçant les zones de javascript par une balise
Mais tout gérer en balise me semble difficile notamment pour certains points que j'ai évoqué dans mon troisième post : ne pas tout concaténer, conserver des libs isolées, telles que celles que l'on peut récupérer sur les cdn de google ou autre.
Ou alors ...
on peut imaginer un système qui ferrait des "append" sur des variables
en haut de mon gabarit je mets :
{cms_script appendTo='sid1' files="assets/js/script1.js;assets/js/script2.js" compression="beautifer" async="true" append="true"}
{cms_script appendTo='sid1' files="cdn.site.fr/jquery.min.js" compression="none" async="true" append="false"}
{cms_script appendTo='sid2' files="cdn.site.fr/script3.min.js" compression="none" async="false" append="false"}
dans le module gabarit je peux mettre
{cms_script appendTo='sid1' files="assets/js/script4.js" compression="beautifer" async="true" append="true"}
dans une page je peux mettre
{cms_script appendTo='sid1' files="assets/js/script5.js" compression="beautifer" async="true" append="true"}
A ce code qui sert de "collecteur" dans deux piles (ici sid1 et sid2) distinctes, on ajoute la partie d'affichage
En haut du gabarit : {cms_script show='sid1'}
En bas du gabarit : {cms_script show='sid2'}
Ainsi le bas de la page web se verrait afficher le script #3, qui est un script volontairement laissé seul, non minifié, parce qu'on ne peut pas le mettre en asyncrone
en haut de la page web on retrouverait les scripts #1#2#4#5 qui seront concaténés ensemble ainsi qu'un appel à la lib jquery, le tout en asynchrone parce que demandé ainsi.
voyez le fonctionnement ? laisser l'utilisateur marquer les points de collecte de lui même d'un côté, et afficher le résultat de l'autre.
L'avantage c'est qu'il n'y a aucune relation page/gabarit qui poserait problème si cette liaison disparait demain.
L'autre avantage c'est qu'il n'y a aucun panel admin nécessaire.
Autre avantage : au résultat n'apparaitront QUE les scripts nécessaires à la page HTML en cours, rien de plus rien de moins.
inconvénient : la gestion des SID demande un sérieux de la part du webmaster
inconvénient : il est difficilement possible de gérer en amont une liste de script "prête à l'emploi" qui seraient utilisable a volonté dans le site, il faut initialiser manuellement d'une manière ou d'une autre les scripts utilisés dans la page.
inconvénient : comment gère t on les fichiers plats ? la solution serait de faire à la volée un hash du contenu du script et utiliser ce hash comme clé du fichier plat js. Ainsi 2 pages utilisant pas de script particulier feront appel au même fichier plat, une Troisième page nécessitant un script en plus aura besoin d'un appel à un autre fichier plat.
clair ?
Mais tout gérer en balise me semble difficile notamment pour certains points que j'ai évoqué dans mon troisième post : ne pas tout concaténer, conserver des libs isolées, telles que celles que l'on peut récupérer sur les cdn de google ou autre.
Ou alors ...
on peut imaginer un système qui ferrait des "append" sur des variables
en haut de mon gabarit je mets :
{cms_script appendTo='sid1' files="assets/js/script1.js;assets/js/script2.js" compression="beautifer" async="true" append="true"}
{cms_script appendTo='sid1' files="cdn.site.fr/jquery.min.js" compression="none" async="true" append="false"}
{cms_script appendTo='sid2' files="cdn.site.fr/script3.min.js" compression="none" async="false" append="false"}
dans le module gabarit je peux mettre
{cms_script appendTo='sid1' files="assets/js/script4.js" compression="beautifer" async="true" append="true"}
dans une page je peux mettre
{cms_script appendTo='sid1' files="assets/js/script5.js" compression="beautifer" async="true" append="true"}
A ce code qui sert de "collecteur" dans deux piles (ici sid1 et sid2) distinctes, on ajoute la partie d'affichage
En haut du gabarit : {cms_script show='sid1'}
En bas du gabarit : {cms_script show='sid2'}
Ainsi le bas de la page web se verrait afficher le script #3, qui est un script volontairement laissé seul, non minifié, parce qu'on ne peut pas le mettre en asyncrone
en haut de la page web on retrouverait les scripts #1#2#4#5 qui seront concaténés ensemble ainsi qu'un appel à la lib jquery, le tout en asynchrone parce que demandé ainsi.
voyez le fonctionnement ? laisser l'utilisateur marquer les points de collecte de lui même d'un côté, et afficher le résultat de l'autre.
L'avantage c'est qu'il n'y a aucune relation page/gabarit qui poserait problème si cette liaison disparait demain.
L'autre avantage c'est qu'il n'y a aucun panel admin nécessaire.
Autre avantage : au résultat n'apparaitront QUE les scripts nécessaires à la page HTML en cours, rien de plus rien de moins.
inconvénient : la gestion des SID demande un sérieux de la part du webmaster
inconvénient : il est difficilement possible de gérer en amont une liste de script "prête à l'emploi" qui seraient utilisable a volonté dans le site, il faut initialiser manuellement d'une manière ou d'une autre les scripts utilisés dans la page.
inconvénient : comment gère t on les fichiers plats ? la solution serait de faire à la volée un hash du contenu du script et utiliser ce hash comme clé du fichier plat js. Ainsi 2 pages utilisant pas de script particulier feront appel au même fichier plat, une Troisième page nécessitant un script en plus aura besoin d'un appel à un autre fichier plat.
clair ?