[bess]

#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: #1.10.3
#~ Url du site :
#~ Hébergeur / Soft :
#~ Informations Système :
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~

Salut tout le monde.

J'ai par le passé eu l'occasion de tester ScriptDeploy que j'avais abandonné car le ratio "temps passé à le configurer + lourdeur" / "gain de perf" me semblais pas assez intéressant.

J'ai eu l'occasion ce matin de re-tester le module et ... OMG c'est pire que tout....

Alors avant d'abandonner totalement le système je voulais avoir vos avis sur ce module.

Son principe pour ceux qui le connaissent pas :

on ajoute des scripts et des feuilles de style, on gère des groupes de scripts
dans le gabarit on appel script-deploy qui va générer un fichier unique CSS / JS selon votre demande.

Plein plein plein d'options sont possibles, caching, minification, ... c'est vraiment complet... mais mon dieu que le système est lourd...

Interface d'administration qui casse la rétine
Utilité de ce module pour le CSS plus que douteuse vu que cms_stylesheet fait déjà la fusion des fichiers et que [[strip]][[/strip]] minifie déjà votre contenu CSS
Mise en cache déjà possible par les instructions .htaccess


bref ... je ressort de là avec l'impression de l'usine à gaz inutile... :/

et vous ?


NB : le vrai point positif dans ce système est la concaténation des fichiers JS qui est une fonctionnalité manquante de cmsms je trouve.

[bess]

ouhaa l’enthousiasme

bon après avoir pleuré sur ce module j'ai décidé de voir la chose autrement.

Donc question, quelqu'un serait il intéressé pour participer avec moi (dev, test, échange d'idée, ...) à la création d'un module qui soit un équivalent à {cms_stylesheet} mais pour du Javascript

Voici quelques idées que j'en ai :

Gestion des scripts :
* ajout/modif/suppress d'un script
* utiliser une lib existante (on donne une url) ou écrire le code direct dans un textarea

Gestion des groupes de scripts :
* ajout de X scripts au sein d'un même groupe (un script pouvant être présent dans différents groupe)
* Organisation de l'ordre des scripts
* option true/false : concaténation du code en sortie. Si false, génèrera autant de balise <script /> que nécessaire.
* option true/false : mise en cache dans un fichier plat horodaté. si false : gestion en dynamique, si un script change, automatiquement le résultat change)
* option true/false : minification en sortie du code.
* option true/false : passage des scripts en mode asynchrone
* option true/false : écriture des balises <script/> en HTML5

Options générales :
* pattern de l'url en sortie, pour bénéficier éventuellement d'un CDN ou d'une écriture à la static.exemple.fr
* choix de la librairie de minification (il en existe de tête 3 grandes sur le net)
* éventuellement options complémentaire sur les choix de minifications, concaténation et autres.


Son utilisation serait du type :

{cms_script group='99'} pour afficher la liste des scripts / un script unique concaténant tous les autres,
{cms_script script='99'} pour afficher automatiquement la balise <script /> du script n°99


Merci de donner vos avis

[heriquet]

Ca peut m'intéresser...

[bess]

J'ai noté ton Tweet sur l'inclusion de-facto des lib de cmsms

j'avais déjà la même idée en tête (bien que pas écrit au dessus), celui de lister les .js dans le répertoire /lib de cmsms pour les proposer de facto comme script connu du module.

pourquoi pas non plus lister les JS les plus connus en dernière version (jquery-lastversion.js) dispo sur les CDN de google

ligthbox, slider, certains sont vraiment récurrents dans nos installations de cmsms

[kraygoon]

Je viens mettre mon grain de sel (de sable ?).
Je ne pense pas que le regroupement de multiples scripts JS en un seul soit une bonne solution. Et pourtant... et pourtant j'ai longtemps été favorable à cette solution... qui finalement pose plus de problème qu'elle n'en résout. Je m'explique.

L'avantage de multiples JS est de pouvoir les mettre en cache, de pouvoir utiliser un "CDN" commun à plusieurs sites (Google, Microsoft ou personnel) et d'éviter le rechargement de scripts identiques.
A vouloir faire un package unique on prend le risque de faire télécharger des ressources déjà en cache.

Des solutions de téléchargement asynchrones existent. Je pense essentiellement à Modernizr. Il y a aussi le script YepNope (intégré à Modernizr) qui permet de ne charger tel ou tel script qu'en fonction du navigateur, de ses capacités. Comment gérer ça avec un seul "gros" fichier JS concaténé ?

Ce gros fichier imposera à vos visiteurs de le retélécharger entièrement si vous ne mettez à jour qu'un seul des scripts qui le compose.

Personnellement, et pour conclure, je suis plus d'avis d'utiliser un CDN. J'envisage de créer le mien pour l'ensemble des mes sites avec un système me permettant de limiter le téléchargement des fichiers le composant aux sites autorisés (htaccess).

[bess]

Je suis essentiellement d'accord avec ton analyse, notamment ce qui concerne l'utilisation d'un CDN commun pour tous les visiteurs et les gains qui en résulte en terme de perf pure

Là où le bât blesse (AMHA) c'est que ton analyse repose sur deux fondamentaux

1 - Tous les responsables de sites sont capables d'utiliser tout seuls la mise en place de code en asynchrones des scripts ... mon dieu... sont ils seulement au courant que ça existe ? sont ils même au courant des soucis liés au pré-chargement + parsing de JS qui bloque le chargement de la page ? sans vouloir me 'la péter', ce n'est pas encore rentré dans les mœurs et seule l'élite des gros geeks barbus se penchent sur ces mesures (oui j'aime les comparaisons poilantes)

2 - Tous les responsables de sites ont le soucis du détail au point de privilégier l'utilisation des libs en CDN de google afin que le visiteur lambda n'ai pas à charger 1 fois la lib de 30ko pour la toute première visite sur son site. Encore une fois je doute que ce soit le cas.

Donc entre le "zéro optim" et le "totalement parfait" je penses qu'on peut proposer un module correcte.



Encore une fois je penses que tu l'as très bien expliqué et je n'ai aucun contre-argument : ta méthode est clairement un "best-practice" ... mais je penses aussi que si l'on prend mon propre exemple : mes lib Jquery sont sur mon hébergement, j'utilise au maximum un sous domaine static.ndd pour gérer le téléchargement simultané > 10 connexions pour toute la partie static de mes sites .... et c'est tout ... du coup parler de CDN, d'optimisation de l'organisation des libs pour éviter le re-téléchargement... ça fait un peu sortir le bazooka pour péter la gueule aux mouches...

Ce gros fichier imposera à vos visiteurs de le retélécharger entièrement si vous ne mettez à jour qu'un seul des scripts qui le compose.

Dit comme cela ça fait presque peur effectivement mais on ne modifie logiquement pas ses scripts tous les mois et même si c'est le cas, on dépasse rarement 200ko de lib


Au final tout est une question de proportion : quelles méthodes appliquer pour quel gain réel.

NB : par contre je trouve effectivement intéressant d'utiliser Modernizr ou autre par défaut dans le gabarit de rendu lié au module, autant ne pas ré-inventer la roue

[bess]

Je rebondit autrement :


Peut on envisager de flagger comme "unconcaténable" certains scripts (option utile notamment pour ceux qu'on file en URL avec le CDN de google), grouper les scripts en un groupement tout a fait normalement, avec d'autres scripts plus personnels, et que le système génère en sortie :

<script src='cdn.google.com/jquery.js' />
<script src='cdn.google.com/jquery_ui.js' />
<script src='static.ndd.tdl/tmp/flaf_file_9999.js' />

Ca résoudrait une grosse partie du problème : on continue d'avoir l'utilité du regroupement de tous les scripts en un seul endroit dans l'admin de cmsms et en + on perd pas l'avantage des CDN mis en place ?

[bess]

j'ai dit un truc qui fâche que plus personne parle

[airelibre]

Salut Bess,

Je me suis gardé ce post dans un coin pour le lire tranquillement, en même temps que je testerai ScriptDeploy. J'ai également un besoin de gestion de mes scripts de plus en plus poussé, et il faut que je regarde de plus près...!

Désolé de pas pouvoir te répondre pour l'instant

[Youpi]

Bonjour,

en effet cette fonctionnalité manque cruellement à Made Simple. Sauf erreur de ma part il n'y a toujours pas a l'heure actuelle de concurrent à ScriptDeploy très (trop?) complet et tres flippant :o.

Après lecture des besoins posés par Bess, je vois 2 solutions:

- soit un module similaire à ce que l'on connait pour la gestion des css avec quelques options en plus (compression ou pas, type compression, concaténé ou pas, async ou pas).

Donc là, ca implique: créations de tables mysql, création de gabarit pour le back end et l'ensemble du code php pour faire le taff.

- Soit, une balise utilisateur reprenant les même options, sous la forme:

Code :

{cms_scripts host="http://static.mondomaine.com" files="assets/js/script1.js;assets/js/script2.js" compression="beautifer/packed/YUI/etc" async="true/false" append="true/false"}

ou encore

Code :

{cms_scripts host="https://ajax.googleapis.com/ajax/libs/" files="jquery/1/jquery.min.js;jqueryui/1/jquery-ui.min.js" append="false"}

La balise utilisateur à pour avantage (je crois ?) d’être utilisable partout alors qu'un module semblable à celui des css n'offrirai que la relation gabarits/fichier JS.

Placé dans les différents champs de modules nécessitant la saisie de JS (ex : gallery > gabarit> javascript), cela permettrai de rassembler dans un seul fichier, chaque portion de JS qu'un module ou gabarit peut produire et ainsi laisser la source HTML vierge de toutes déclarations inline.


L'objectif étant d'avoir, par page qui nécessite des ressources Javascript:

- 1 balise script par librairie chargé (afin profité de la parallélisation des téléchargements).
- et 1 seule balise script appelant un fichier "local" nommé "alias-de-la-page-(md5 ou time).js, qui contiendrait les codes JS concaténé, que nécessite la page.
- Si nécessaire chargé en Javascript plus de ressource JS.


Cela fait bien 2 ans que je n'avais pas réinstaller un CMS MS et je suis agréablement surpris des progrès réalisé depuis.

J'ai un peu de temps et surtout et besoin de cette fonctionnalité pour un développement.

Je vais faire quelques test en attendant vos remarques !

[heriquet]

Moi je me lance dans des appli web et je compte les intégrer dans des cmsms pour les parties "gestion de contenu" et autre...

Donc on pourrait se faire un petit "groupe de travail" avec les personnes intéressées !

[bess]

salut youpi

peux-tu creuser cette partie stp ?

Placé dans les différents champs de modules nécessitant la saisie de JS (ex : gallery > gabarit> javascript), cela permettrai de rassembler dans un seul fichier, chaque portion de JS qu'un module ou gabarit peut produire et ainsi laisser la source HTML vierge de toutes déclarations inline.

sinon pour répondre à Hériquet :

Donc on pourrait se faire un petit "groupe de travail" avec les personnes intéressées !

Je monte demain (parce qu'actuellement je navigue toujours 20 000 lieux sous les merdes) une repo github. Chacun apportera sa pierre à l'édifice une fois que l'on sera d'accord sur les modalités (module ou plugin ?)

Il me semble même que certain dév anglais était intéressés par l'idée (vu sur twitter), avec un peu de chance ils fileront un coup de main.

Voyons grand ! Je pensais mettre en place des api dans le module (si c'est un module) afin de permettre aux autres modules d'aller faire enregistrer les scripts qui leur sont nécessaires. Un peu comme CgExtension qui est beaucoup utilisé par les autres modules pour auto-générer certains formulaires de backoffice

[heriquet]

Je pensais mettre en place des api dans le module (si c'est un module) afin de permettre aux autres modules d'aller faire enregistrer les scripts qui leur sont nécessaires.

Là ca serait l'idéal... je pense que tous les développeurs de modules seront d'accord avec moi !

C'est chiant d'ajouter des scripts JS dans les pages ou ils sont nécessaires.

En pouvant les intégrer depuis le module, on s'éviterait pas mal de travail au sein même des pages de contenu.

Mais il faut garder à l'esprit que l'inclusion d'un fichier JS unique pose problème : soit TOUS les scripts sont ajoutés partout -ce qui veut dire un gros fichier pour toutes les pages et donc un temps de latence la première fois, ce qui est bien mais n'oublions pas que Google semblerait tenir compte du temps de chargement d'une page pour son ranking... donc ce que nous gagnerions dans un domaine, serait perdu dans un autre-.

Et en compactant les fichiers nécessaires à chaque page, le temps de chargement de la dite page à la seconde consultation diminue mais les ressources partagées entre plusieurs pages seraient dupliquées dans chacun de ces fichiers JS.

Difficile de trouver le juste milieu .

[bess]

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 ?

[heriquet]

Oui clair...

Pour ce qui est du sérieux du webmaster, moi je dis qu'on ne doit pas en tenir compte. (même si CMSMS doit rester "Simple")

Quand on veut faire du travaille de professionnel, on agit en professionnel. Sinon on laisse faire un professionnel.

Moi j'aime bien la notion de scripts "statiques" et de scripts "propres à une page". Y a toujours un tronc commun (pour ne pas citer jQuery) et une partie "variable" comme par exemple une animation ou les contrôles d'un formulaire de contact. Donc si on parvient à trouver un juste équilibre entre ces 2 notions, on doit pouvoir faire quelque chose de bien.

Dans l'API, je verrais bien un tab dans la partie de l'admin "Administration du site - Paramètres globaux" qui permettrait de choisir quels scripts sont les scripts "communs" et dans l'onglet "Options" d'une page, on peut choisir quels sont les scripts additionnels.

Et alors il faudrait pouvoir faire des fichiers JS comme pour les feuilles CSS et les joindre ou pas à une page, comme on le ferait pour un gabarit avec une feuille CSS (et éditable par TemplateExternaliser également).

Je crois honnêtement que les quelques lignes de JS utiles à valider des formulaire, animer des galeries ou autre peuvent se trouver au sein d'un même fichier JS disponible partout mais en laissant le choix de l'inclure ou non car une "bête page de texte" ne nécessitant pas de script a le droit d'en être dispensée ! Dont gain de performance à l'affichage car une requete HTTP en moins.

Qu'en pensez-vous ?

[Youpi]

@Bess:

En fait je tenté d'exprimé ce que d'autre appelle des hooks.

je veux pouvoir placer {cms_script} a différents endroits, comme les gabarits, les modules, voir dans {content} et voir en sortie une balise script, un seul fichier contenant tout le Javascript (regroupant les appels soumis au meme options, ex: async, append, host), "accroché/receptionné" par les appels a {cms_script}.

Exemple !

Dans le <head> mon gabarit:

Code :

{cms_scripts host="https://ajax.googleapis.com/ajax/libs/" files="jquery/1/jquery.min.js;jqueryui/1/jquery-ui.min.js" append="0" async="1"}
{cms_scripts host="http://static.mondomaine.com/assets/js/" files="menu-hover-v12.js;scrollToMe.js" compression="YUI" async="1" append="1"}

Dans mon gabarit de "Gallery", champs 'Gabarit HTML' (j'ai testé dans gabarit Javascript ca ne fonctionne pas) :

Code :

{cms_scripts host="http://static.mondomaine.com/assets/js/" files="gallery-v8.js" compression="packed" async="1" append="1"}

Et enfin dans la page contact:

Code :

{contact_form}
{cms_script host="http://static.mondomaine.com/assets/js/" files="form-control.js" compression="YUI" async="0" append="1"}

Qui resulterai en

Code :

[== HTML ==]
...
<head>
<!--2 balises distinctes car append="0" a l'appel -->
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" async="async"></script>
<script src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.16/jquery-ui.min.js" async="async"></script>

<!--contient menu-hover-v12.js suivi de scrollToMe.js minifier via YUI, suivi de gallery-v8.js minifier via packed. -->
<script src="http://static.mondomaine.com/tmp/cache/script_combined_c9f1d0865401fa704035641380a9bddf.js" async="async"></script>

<!--contient form-control.js minifier via YUI. mais pas concaténé car async="0" -->
<script src="http://static.mondomaine.com/tmp/cache/script_combined_k8f2d0868941fa704035641380a9hggf.js" async="async"></script>
</head>
...

Par cette exemple, j'essaie de démontrer que, quelques soit le point de vue sur "la meilleure façon de faire", cette balise/plugin offrirai une gestion simple et précise du Javascript.


Je pense que le plugin suffit et que la création d'un module abouti, s’apparenterait a une copie de scriptDeploy allégé / reskinné ?

[bess]

plutôt que de partir sur un postulat

Je crois honnêtement que les quelques lignes de JS utiles à valider des formulaire, animer des galeries ou autre peuvent se trouver au sein d'un même fichier JS disponible partout mais en laissant le choix de l'inclure ou non car une "bête page de texte" ne nécessitant pas de script a le droit d'en être dispensée !

ne devrait pas être un comportement définit par l'application, mais un résultat du paramétrage de l'application par l'utilisateur.

Autrement dit, on doit pouvoir faire ce que tu décris, mais également être capable de faire autrement (un énorme bloc de script pour tout, tout tout)

tu parles de tronc commun, on peut le décrire dans une partie de l'administration effectivement, mais on peut également le déclarer en haut d'un gabarit / de tous les gabarits ce qui reviendrait au même.

L'avantage que j'essaie de conserver c'est de garder une souplesse maximale pour le webmaster dans son paramétrage et une légèreté pour le système si on arrive à nos fins sans rien stocker en base et donc ne pas passer par des requêtes sql de jointures sur condition (select * from script where templateid = ....)

[heriquet]

Un paramétrage via la DB n'empêche pas la génération de flat files si ?

Moi je dis ca car c'est bien pratique le module de gestion des templates avec les associations d'éléments réalisable si facilement !

[heriquet]

Moi je verrais bien un système de "sid" comme tu l'évoquais et alors la possibilité de tout mettre dans le même "sid" pour avoir UN gros fichier ou alors pouvoir définir plusieurs sid et les associer aux pages voulues. C'est de l'optimisation et ca reste totalement paramétrable par l'intégrateur.

[bess]

je suis de l'avis de youpi. une balise (ou un plugin, ou un module sans interface) devrait être privilégié pour rester totalement paramétrable.

Faire un panel admin va certainement permettre les "moins compétents" d'entre nous à mieux visualiser ou ils en sont, mais forcement ça va alourdir le système.


Reste un point que sera facilement contournable : catcher un bloc de script


{capture assign='mon_script'...}<script> blab blabla </script>{/capture}
{cms_scripts files="$mon_script" compression="packed" async="1" append="1"}

le système sachant faire la différence entre du contenu et un lien vers un script

[bess]

Moi je verrais bien un système de "sid" comme tu l'évoquais et alors la possibilité de tout mettre dans le même "sid" pour avoir UN gros fichier ou alors pouvoir définir plusieurs sid et les associer aux pages voulues.

oui faire un {cms_script appendTo='sid1,sid2' files="assets/js/script1.js;assets/js/script2.js"} devrait permettre de distribuer les librairies à différentes piles.

Interagir avec la bdd ne sera pas un frein à la génération de fichiers plats, je ne pensais pas à cela. Pour moi gagner 2 requêtes SQL par pages, c'est toujours cela de gagné, et donc si on évite d'interagir avec la bdd je penses que c'est mieux.

[heriquet]

Bah en utilisant des fichiers plats basés sur le contenu de la DB... on garde un peu de Made Simple tout en permettant d'optimiser ...

Rien n'empêche d'avoir un petit bouton "Générer les JS" quelque part dans l'admin !

On peut aussi gérer cela dans un fichier XML plutôt que la DB.

[Youpi]

Pour l'aspect 'sid', je pensais laissé le plugin décidé de la répartition et groupement sur la base des paramètres que l'on passe.

Dans l'ordre par host >> async||defer||rien >> files:position;du;nom;de;fichier


Après pourquoi pas, car ça offre encore plus de contrôle, peut-être en gardant le comportement ci-dessus par défaut.

Reste un point que sera facilement contournable : catcher un bloc de script

{capture assign='mon_script'...}<script> blab blabla </script>{/capture}
{cms_scripts files="$mon_script" compression="packed" async="1" append="1"}

le système sachant faire la différence entre du contenu et un lien vers un script

bien vu, dans ce cas peut être prévoir un énième paramètre 'script' et on laisse 'files' s'occuper de fichiers hébergés:

{capture assign='mon_script'...}<script> blab blabla </script>{/capture}
{cms_scripts script="$mon_script" compression="packed" async="1" append="1" files="script.js;script2.js"}


Par ailleurs, je n'ai jamais utilisé git, mais pourquoi pas pour mettre tout ça a plat dans un wiki ou autre.

[bess]

sur la forge : http://www.cmsmadesimple.fr/forum/viewto...789#p25789
sur github : https://github.com/besstiolle/cms_script

si tu connais le fonctionnement des CVS & SVN tu devrais pas être chamboulé

Github possède un wiki accessible aux contributeurs du projets, inscrivez vous et je vous mets dessus