Quelques remarques:
• Place la balise <meta charset.../> en premier. En effet, la <meta charset.../> [...] doit apparaître parmi les 512 premiers octets de la page car certains navigateurs ne consultent seulement ces premiers octets pour déterminer l'encodage utilisé pour la page. (Source: MDN). Si le titre de la page dépasse cette longueur, des surprises apparaitront...
• Utilise [ code=html ] ou [ html ] ou au pire [ code=xml ] pour tes encarts de code dans tes posts.
• Perso, les $this qui se promènent au milieu de nulle part, dans le code PHP compilé, j'aime moyen, mais disons que c'est du code compilé (temporaire, interne), donc l'humain n'a pas à le lire
• Que se passe-t-il quand plusieurs utilisateurs vont vouloir une même page? Ton système de template risque de créer une page pour l'utilisateur1, puis une pour l'utilisateur2 (qui écrase celle du 1), puis il fera le requi_reonce de l'utilisateur1, et donc celui-ci verra la page de l'utilisateur2. Creuse ce qui concerne les Systèmes de verrou de fichier pour éviter cela, et les Systèmes concurrents (PDF) pour la culture.
• Sur la rédaction, c'est bien écrit, pas de soucis
• Le template n'offre aucune notionanti-XSS, comme le ferait XSL: si la variable $this->data[] contient du code HTML, il sera interprété comme tel, et non comme du texte. Mieux vaudrait également que template.cache.php ne soit pas accessible de l'extérieur (cad depuis le web).
• Niveau OO, le moteur de template s'occupe de plusieurs (trop?!) de choses: remplacer les variables dans le template, le sauver dans un fichier, le charger depuis ce fichier, et même, vérifier que les varables d'entrée existent... Découper en plusieurs classes me semble donc plus approprié. L'intérêt étant que la classe de sauvegarde dans un fichier pourra alors céder sa place à une classe de sauvegarde dans le flux php://memory ou php://temp, sans toucher au moteur de template. La simplicité de l'informatique n'est pas dans la création de lib à 1~2 classes, mais dans la création de systèmes fragmentés où changer un p'tit bout n'affecte pas les autres morceaux.
• Note que si tu fais ta propre syntaxe de template (je sais pas si c'est exactement le cas ici), alors tu ne bénéficieras pas d'un autre intérêt des libs et des langages standardisés: leur prise en charge par les IDE (coloration syntaxique, refactoring,...)
• Tu parles de la possibilité d'ajouter d'autres capacités au moteur, mais tu l'appliques de travers: privilégie l'open-closed principle au lieu de la modification de ta classe. Sinon, plus tu voudras ajouter de possibilités au moteur de templates, plus ta classe deviendra un énorme fourre-tout.
• Si tu fais un {%FOR%} sans le {%ENDFOR%}, ton moteur de template risque de tourner zinzin... Là, tu essaye finalement de refaire un lexer/parser en PHP. Niveau perfs, ce sera mauvais, et tu risques de tomber sur des schémas syntaxiques qui vont faire planter ton système (cf 1ere ligne de ce point).
• Dans ton foreach, tu utilises $this->data au lieu de $this->_show_var(). Note d'ailleurs que les appels de fonctions étant lents en PHP, une boucle qui appelle des fonctions risque d'être un goulet d'étranglement.
Bonne chance pour les corrections
• Place la balise <meta charset.../> en premier. En effet, la <meta charset.../> [...] doit apparaître parmi les 512 premiers octets de la page car certains navigateurs ne consultent seulement ces premiers octets pour déterminer l'encodage utilisé pour la page. (Source: MDN). Si le titre de la page dépasse cette longueur, des surprises apparaitront...
• Utilise [ code=html ] ou [ html ] ou au pire [ code=xml ] pour tes encarts de code dans tes posts.
• Perso, les $this qui se promènent au milieu de nulle part, dans le code PHP compilé, j'aime moyen, mais disons que c'est du code compilé (temporaire, interne), donc l'humain n'a pas à le lire
• Que se passe-t-il quand plusieurs utilisateurs vont vouloir une même page? Ton système de template risque de créer une page pour l'utilisateur1, puis une pour l'utilisateur2 (qui écrase celle du 1), puis il fera le requi_reonce de l'utilisateur1, et donc celui-ci verra la page de l'utilisateur2. Creuse ce qui concerne les Systèmes de verrou de fichier pour éviter cela, et les Systèmes concurrents (PDF) pour la culture.
• Sur la rédaction, c'est bien écrit, pas de soucis
• Le template n'offre aucune notionanti-XSS, comme le ferait XSL: si la variable $this->data[] contient du code HTML, il sera interprété comme tel, et non comme du texte. Mieux vaudrait également que template.cache.php ne soit pas accessible de l'extérieur (cad depuis le web).
• Niveau OO, le moteur de template s'occupe de plusieurs (trop?!) de choses: remplacer les variables dans le template, le sauver dans un fichier, le charger depuis ce fichier, et même, vérifier que les varables d'entrée existent... Découper en plusieurs classes me semble donc plus approprié. L'intérêt étant que la classe de sauvegarde dans un fichier pourra alors céder sa place à une classe de sauvegarde dans le flux php://memory ou php://temp, sans toucher au moteur de template. La simplicité de l'informatique n'est pas dans la création de lib à 1~2 classes, mais dans la création de systèmes fragmentés où changer un p'tit bout n'affecte pas les autres morceaux.
• Note que si tu fais ta propre syntaxe de template (je sais pas si c'est exactement le cas ici), alors tu ne bénéficieras pas d'un autre intérêt des libs et des langages standardisés: leur prise en charge par les IDE (coloration syntaxique, refactoring,...)
• Tu parles de la possibilité d'ajouter d'autres capacités au moteur, mais tu l'appliques de travers: privilégie l'open-closed principle au lieu de la modification de ta classe. Sinon, plus tu voudras ajouter de possibilités au moteur de templates, plus ta classe deviendra un énorme fourre-tout.
• Si tu fais un {%FOR%} sans le {%ENDFOR%}, ton moteur de template risque de tourner zinzin... Là, tu essaye finalement de refaire un lexer/parser en PHP. Niveau perfs, ce sera mauvais, et tu risques de tomber sur des schémas syntaxiques qui vont faire planter ton système (cf 1ere ligne de ce point).
• Dans ton foreach, tu utilises $this->data au lieu de $this->_show_var(). Note d'ailleurs que les appels de fonctions étant lents en PHP, une boucle qui appelle des fonctions risque d'être un goulet d'étranglement.
Bonne chance pour les corrections