Wiki - 1 output

Pourquoi un cache

L’implémentation de l’AOP dans le framework it.rocks nécessite la modification de votre code source PHP, pour y ajouter les mécanismes nécessaires aux appels AOP en tissage semi-dynamique.

L’AOP étant le mécanisme de base utilisé par @getters, @setters, Annotation de propriété @link et plugins, le cache doit toujours être à jour pour que votre logiciel s’exécute conformément à ce que vous avez demandé dans son code source.

Choses à savoir concernant le cache

• Les scripts qui ont été modifiés, et ceux qui en dépendent, sont recompilés vers le cache dès qu’on a un fichier (vide) update dans la racine du projet. l’IDE PhpStorm par exemple permet d’ajouter un Files Watcher qui vous permettra d’automatiser la création d’un fichier update à chaque fois que vous modifiez un script PHP, pour que cette tâche qui serait fastidieuse manuellement soit automatisée. Un utilitaire de gestion de workflow tel que Gulp peut permettre également cette automatisation.

En effet le framework supprime le fichier update dès qu’il a recompilé, pour vous permettre de naviguer le plus rapidement possible dans le logiciel même lorsque vous êtes en configuration de développement.

• Lorsqu’un fichier flag update est présent, le framework scanne tous les fichiers du projet pour savoir quelle partie du cache il doit recalculer : en principe seulement les scripts qui ont été modifiés et ceux qui peuvent être impactés indirectement (classes filles par exemple, entre autres). Ce scan est relativement rapide, la recompilation également.

• Lorsqu’on modifie des classes sensibles, proches du coeur, comme l’est Main par exemple, il se peut qu’elles soient chargées avant la recompilation du cache. Le prochain clic après une modification dans Main exécutera donc le Main d’origine, c’est le prochain clic qui verra s’exécuter le nouveau code compilé.

• Lorsque les scripts sont recompilés et mis en cache, la disposition de leur code reste inchangée au maximum par rapport au script d’origine : la mise en cache permet principalement de faire fonctionner l’AOP : au pire on renomme donc des méthodes en leur rajoutant un ‘_’, puis du code supplémentaire à ces méthodes est ajouté en fin de classe / script. C’est pour ça qu’au débogage pas à pas, avec xdebug par exemple, on se retrouve parfois dans du code “après la fin du script courant” invisible, ce qui peut être perturbant au premier abord.

• Pour déboguer pas-à-pas directement dans le fichier du cache et voir comment ça fonctionne, c’est possible : il faut ajouter le paramètre $_GET nommé D (débogage) à l’URL qu’on veut déboguer. Attention : ?D ajoute également de l’affichage notamment pour la recherche automatique des chemins de contrôleurs, vues, et templates HTML. C’est assez verbeux. Voyez Paramètres _GET magiques pour en savoir plus.