26-02-2015, 07:00 AM
Merci pour ces remarques Xenos, comme d'habitude 
-C'est vrai que la regex est peu regardante, mais je prévois l'utilisation de variables comme suit : {{mon_objet->id | int | esc }} donc je ne peux pas être restrictif :/
Mais je pourrai virer le 's' au moins.
- L'injection : filename provient du développeur, qui a également en charge de vérifier le dossier 'cache'. Si on ne peut pas faire confiance aux dévs.. ^^ Cette partie (comme beaucoup) doit encore évoluer.
- FileCache : C'est mon moteur de cache, qu'il est possible de substituer par un autre (héritier de AClass).
AClass, classe abstraite, permet de définir les options du cache avec 'configure'. Ainsi, même si le développeur n'a pas accès à l'objet Cache, il peut tout de même en définir les options grâce à 'cache_configure' dans la classe Tpl.
Moins souple que la composition ?
- Oui c'est prévu de commenter et documenter un minimum sur GitHub.
Pour la license, oui c'est à peu près ça. Je pensais à MIT aussi, à voir.
- eval(), c'est la seule manière que j'ai trouvé pour pouvoir évaluer le code compilé provenant de n'importe quelle source.
En l'état j'aurai pu faire un require sur le cache (s'il est actif), mais si le cache est écrit en DB par exemple, impossible. Il faut que je teste plusieurs méthodes d'injection mais ça revient de toute façon au même qu'un include.
- En effet pour ob_start.
J'ai essayé de faire ça simplement en appliquant le principe SOLID. En revanche, j'ai toujours un peu de mal avec le principe de responsabilité unique (où est-ce qu'on arrête de déléguer ??? ^^ ).
Il manque beaucoup de choses (surtout niveau sécurité) même si ça n'a plus rien à voir avec le code d'origine..
Merci !
-C'est vrai que la regex est peu regardante, mais je prévois l'utilisation de variables comme suit : {{mon_objet->id | int | esc }} donc je ne peux pas être restrictif :/
Mais je pourrai virer le 's' au moins.
- L'injection : filename provient du développeur, qui a également en charge de vérifier le dossier 'cache'. Si on ne peut pas faire confiance aux dévs.. ^^ Cette partie (comme beaucoup) doit encore évoluer.
- FileCache : C'est mon moteur de cache, qu'il est possible de substituer par un autre (héritier de AClass).
AClass, classe abstraite, permet de définir les options du cache avec 'configure'. Ainsi, même si le développeur n'a pas accès à l'objet Cache, il peut tout de même en définir les options grâce à 'cache_configure' dans la classe Tpl.
Moins souple que la composition ?
- Oui c'est prévu de commenter et documenter un minimum sur GitHub.
Pour la license, oui c'est à peu près ça. Je pensais à MIT aussi, à voir.
- eval(), c'est la seule manière que j'ai trouvé pour pouvoir évaluer le code compilé provenant de n'importe quelle source.
En l'état j'aurai pu faire un require sur le cache (s'il est actif), mais si le cache est écrit en DB par exemple, impossible. Il faut que je teste plusieurs méthodes d'injection mais ça revient de toute façon au même qu'un include.
- En effet pour ob_start.
J'ai essayé de faire ça simplement en appliquant le principe SOLID. En revanche, j'ai toujours un peu de mal avec le principe de responsabilité unique (où est-ce qu'on arrête de déléguer ??? ^^ ).
Il manque beaucoup de choses (surtout niveau sécurité) même si ça n'a plus rien à voir avec le code d'origine..
Merci !