Forum CMS Made Simple FR

Nouveau module codé par Youpi et moi même (et vous ?) suite à cette discussion.

Ce topic servira à centraliser nos échanges, vos questions, toussa toussa...


Les liens relatifs au projet :

La forge (utilisable plus tard)
Projet Github, actuellement en version nightly ( = risque pas de fonctionner).
Wiki du projet

+ j'ai ajouté les classes Vector et Script pour gérer la file de script et pour gérer les propriétés de chaque scripts
+ j'ai finalement intégré ces deux classes dans le code existant, le rendu fonctionne impeccable (voir le TESTME pour + d'info)

Concernant la mise en cache des scripts, j'ai en tête un moyen ultra rapide qui devrait pouttrer niveau temps de traitement

On a 3 paramètres possibles :
* file
* url
* smarty

soit SID l'identifiant du cache :

SID = md5( md5(file.timestamp + file.name) + md5(url.name) + md5(smarty.value) [....] )


en gros on parie sur le fait que si une date de création de fichier ne change pas et que son nom ne change pas, si une url ne change pas, alors leur contenu reste le même d'une opération à l'autre.

Pour smarty on est obligé de tester le contenu de toute façon.

Donc dans le cas présent si je modifie le contenu du fichier, le contenu de smarty ou si je fais un changement d'adresse url : le md5 global sera différent, donc besoin de regénérer le cache.

A l'inverse : faire un md5 sur le contenu des fichiers ou le contenu de l'url serait un sacré temps de perdu, inutile de le faire je pense

Voilà pour mes recherches de la soirée.

Je viens de comparer avec le projet Minify, et eux ne s’embarrassent pas et compare les contenus de fichiers afin de détecter une mise a jour et agir en fonction.

Un script étant rarement supérieur à 200ko. le md5 du contenu d'un fichier reste la meilleur façon de savoir si son contenu a changé ou pas. Ta solution me semble équivalente dans la finalité (elle ne doit pas couvrir 100% des cas, mais j'avoue ne pas trouver d’exception pour le moment), mais elle est a coup sur plus rapide et moins gourmande que du md5 de ficher entier c'est certains !

J'ai 2 questions:

- Concernant les paramètres: Est-ce que file.name et file.url, ne pourrait pas être regroupé en file.uri, pouvant contenir une chaine relatant d'un path local ou externe. (ex: 'assets/js/mon_script.js' mais aussi 'http://mon.cdn.com/mon_script.js'). Impliquant certes la distinction via php, mais simplifiant la compréhension et l'utilisation du module.

- Concernant la création du md5: ne vaudrait-il pas le coup de simplement faire pour les uri's:

md5(file.timestamp + file.uri + file.filesize)

et pour les blocks de scripts :

md5(smarty.value + block.size).

La chaine reste représentative de l'état du cache a un instant 'T' et ça évite de faire du md5 de md5 !

Ta première question est une question a poser aux autres, je ne pense pas personnellement que 3 options soient énormes (file|url|smarty) et comme tu l'as dit, ça implique de laisser php devoir gérer la distinction des deux y compris dans le métier. Or le traitement des fichiers présents sur disque peut éventuellement être différent qu'un fichier distant telles que la réécriture d'url par exemple http://www.site.fr/lib.js => http://static.site.fr/lib.js. mais ce n'est que mon opinion, donc a débattre.

pour le MD5,

md5(file.timestamp + file.uri + file.filesize) me semble superflu , file.timestamp + file.uri devant suffire à eux seul mais ce n'est pas une pénalité de temps de traitement donc ok.

md5(smarty.value + block.size) me semble par contre inutile puisque smarty.value sera toujours != si smarty.size a changé, donc tester smarty.size est inutile, tester smarty.value est suffisant.

Par contre je me dit que j'ai du mal m'exprimer quand je disais SID l'identifiant du cache, je parlais de l'ensemble de tous les scripts , d'où la nécessité de faire un md5 de tous les md5 de tous les scripts présents

Dernier point : si l'on partait du principe que l'on regroupe file + url en uri => il est impossible de connaitre avec certitude le poids d'un fichier distant (tous les serveurs ne retournant pas l'information dans le header de retour)

bess a écrit :Ta première question est une question a poser aux autres, [...] , ça implique de laisser php devoir gérer la distinction des deux y compris dans le métier. Or le traitement des fichiers présents sur disque peut éventuellement être différent qu'un fichier distant telles que la réécriture d'url par exemple http://www.site.fr/lib.js => http://static.site.fr/lib.js [...]

En fait la question réside dans :

Citation :"Est-ce que l'on optimise aux max. pour l'utilisateur de façon opaque au dépend des perfs. du module, ou bien on laisse la possibilité de créer des appels moins optimisés ?".

Moi j'opterai pour la première, dans le sens ou l'utilité du modules réside, entre autres, dans le gain de performance en terme de front-end. Et vous ?

Pour la formule du MD5, tu as raison, file.filesize est superflu, je m'aligne.

Idem pour block.size, la ce serait clairement inutile.

bess a écrit :Par contre je me dit que j'ai du mal m'exprimer quand je disais SID l'identifiant du cache, je parlais de l'ensemble de tous les scripts , d'où la nécessité de faire un md5 de tous les md5 de tous les scripts présents

D'accord, en effet, le md5 d'un fichier de cache = md5( de la concaténation de tout les md5(cf: formule décrite par Bess) de chaque fichiers/blocks que contient ce même fichier cache).

je recolle l'échange d'email pour pas se disperser

Citation :de mon côté j'ai pas mal avancé sur la gestion des hash, sur la création de 3 classes qui extends Script pour mieux séparer le métier et sur la distinction par Stack des scripts

Donc pour moi la partie front-office se passe très bien, pas de mauvaise surprise.

Youpi s'occupe du BackOffice

Si certains ont des questions ou ont envie de participer il y a encore matière à faire !