MOTEUR DE TEMPLATE

Commentaire de coucou747 le 24/10/2008 09:35:00 administrateur CS

salut

super code !

t'as juste une verification d'erreurs a ajouter apres les fopen et choses du genre.

Commentaire de neigedhiver le 24/10/2008 14:36:06

Salut,

J'ai pas bien eu le temps de tout regarder en détails bien que ce genre de source m'intéresse.
Cependant, il y a un truc qui m'a choqué : c'est le constructeur style PHP4.
Bien que ce soit compatible en PHP5, si on étend ta classe, il faut appeler manuellement le constructeur du parent. Or, le constructeur __construct() en PHP5 permet justement de s'affranchir de cette "contrainte"...

Je regarde ça plus en détails ce week end, et je bencherai pour comparer avec le mien :)

En tout cas, ça fait plaisir de voir de temps en temps des sources soignées et documentées.
A propos de la doc... Quel standard respectes-tu ? Pour ma part, je suis habitué à phpDoc (syntaxe identique ou presque à javaDoc, pyDoc), du coup là, ça me perturbe un peu ^^ (mais c'est pas grave...)

Commentaire de kankrelune le 24/10/2008 18:52:23

Zut crotte flute j'ai oublié de noter... au passage utiliser les fonctions f****() c'est bien mais faut les tester aussi si l'ouverture du fichier foire ton fread() risque de pas aimer derrière... .. . ;o)

@ tchaOo°

Commentaire de codefalse le 24/10/2008 23:04:44 administrateur CS

@Kankrelune : Pour file_get_contents, j'effectue les tests avant (file_exists && is_readable), et ensuite je test le retour de file_get_contents, donc ca devrait le faire. Après niveau perf, jamais essayé ! :)

Par contre je suis totalement contre l'idée d'intégrer un gestionnaire de cache dans un moteur de template (en règle générale). Beaucoup de tests de templates les évaluents avec un moteur de cache, mais ce n'est pas la règle de base du monde Unix de ne faire qu'UN truc, mais le faire bien ? Un moteur de template, ET, a coté, un moteur de cache.
Je vois absolument pas la liaison entre un moteur de cache et un moteur de template :

$oCache = new MyCache ();
if ($oCache->isInCache ($_SERVER['PHP_SELF'])) // C'est du vite fait, juste pour donner l'idée
     echo $oCache->retrieveFromCache ();
else {
     $oTpl = new MyTemplate ('MyFile.tpl');
// Traitements
     echo $oTpl->render ();
     $oCache->save ();
}

Mettre un système de cache dans un moteur de template alourdit le code et ne sert strictement à rien à part transformer le code en un vrai charabiat :p

Bon, après ca c'est mon point de vue, et je sais que beaucoups de gens ne pense pas comme moi, mais je serai intéressé de connaître une bonne raison de mélanger les deux :)

Jte met 7 (pareil, c'est mon interprétation ;) :p)

Commentaire de FaustXVI le 25/10/2008 12:30:03

Bonjour à tous,

déjà merci pour vos remarques!
Je vais faire une mise à jour du code bientôt, j'ai de la famille à la maison ce week-end donc il va falloir être un peux patient :-(!
Pour la doc j'utilise doxygen qui est un system de documentation multi langages donc pas besoin de changer entre le C le C++ le Java (même si la j'utilise Javadoc...) le PHP etc...
J'ai juste une question sur les test à faire après le fopen :
avant d'ouvrir en lecture le fichier, je test s'il est présent et lisible donc logiquement je ne devrais avoir aucune erreur possible sur fopen non??

Commentaire de alphanono le 27/10/2008 09:21:11

Salut, pas mal du tout. Pareil que Codefalse, la gestion des exceptions est amusante ;)

Pour info, une autre façon de traiter la capture du template (celle que j'utilise) dans les grandes lignes :
if(file_exists($_fichierTpl)){
  ob_start(); // Démarre la capture dans le buffer
  require $_fichierTpl; // Inclue le template. De cette façon, le code php dans le template pourra être exécuté
  $this->template = ob_get_contents(); // Récupère le contenu du buffer
  ob_end_clean(); // Vide le buffer
} else {
  $this->template = "Fichier introuvable : " . $_fichierTpl;
}

Ca peut être utile dans certains cas, ça me permet d'exécuter du code php dans les templates au moment de l'appel.
De plus, cette façon de faire me donne la possibilité d'écrire pendant l'exécution un morceau de template en y plaçant du code php puis de rappeler ce template précalculé pour lui faire exécuter le code php qui lui a été intégré en différé ...
Enfin, y'a plein de possibilités avec cette méthode, même si ce n'est pas ce qu'on utilise le plus fréquemment dans un moteur de template.

Juste une implémentation nécessaire à mon avis : la gestion de conditions. J'utilise fréquemment des conditions qui vont faire qu'un bloc doit s'afficher ou non une fois le template calculé. Avec ma syntaxe :

{?condition?}
<h2>mon titre secondaire</h2>
{?/condition?}

Et on affecte un Boulean sur la variable condition. A true, il affichera le titre, à false, il n'affichera rien.

Commentaire de alphanono le 27/10/2008 10:51:19

lol ... tu comprendras le besoin venu ;)
Mais le MVC n'a rien contre le php dans les templates. Tout dépend de son utilisation. Bien souvent, on utilise même des fichiers (souvent notés en .phtml) qui sont des fichiers de templates représentant des parties html de la page à générer. A l'intérieur de celles-ci, on a des appels vers des méthodes du Modèle qui va interpréter la demande et renvoyer la réponse dans le template.
Par exemple, dans ton Modéle, tu as une gestion d'images.
Dans ta Vue (ton template), tu veux afficher une vignette.
Dans ta vue, tu auras un appel $model->image(fichier,50,50) pour calculer la vignette en 50x50 et la renvoyer à la page. Ce système est bien valide MVC car ces changements de taille des vignettes sont bien liés à la Vue mais calculés par le Modèle.

Commentaire de codefalse le 27/10/2008 15:12:28 administrateur CS

A la base, PHP est un moteur de template, donc l'utiliser en tant que tel ne pose pas de problème du tout. La principale raison qui fait que certaines personnes sont contre son usage en tant que moteur de template, c'est le fait que le graphiste peux avoir accès à certains éléments et agir en tant que controlleur là ou il ne devrait faire que des conditions ou des boucles, chose qui n'est pas possible avec un moteur de template à part entière.

@Kankrelune : Personnellement je suis partisans du "chaque truc fait une chose mais le fait bien", donc je reste persuadé qu'un système de cache n'a rien à faire dans un moteur de template. Pour pousser aux extrêmes, ce serait comme intégrer tout un site dans un fichier :p
Maintenant c'est très bien que l'on ait pas la même vision de la chose, c'est en partageant nos points de vues que les choses évoluent :)

Commentaire de lleriche le 30/10/2008 20:05:35

un exemple d'utilisation ou de pages réalisées avec ?

car si je comprends le résultat d'un bloc sera toujours du type <ul> ?

Commentaire de verdy_p le 02/11/2008 19:40:58

Il n'est pas inutile de rappeler qu'il existe un moteur de template très performant, très utilisé, intégrant la gestion d'un cache et supportant l'édition dynamique des "templates" (ou modèles) pour la génération de code HTML: MediaWiki (ex.: Wikipedia, Wikimedia Commons, Wiktionary, etc. et la plupart des wikis actuels).

Ceci dit un tel code n'est pas inutile pour générer autre chose que du HTML pour un site web; par exemple pour générer du XML tel qu'une image SVG (mais MediaWiki possède de telles extensions permettant de générer toutes sortes de documents à partir de modèles et de données dans une approche de type document-view permettant la séparation du modèle de données et des formulaires ou pages de présentation de ces données.)

On a aussi besoin d'autres templates pour générer des interfaces graphiques XML (par exemple en XUL) ou faire des transformations de données XML, ou manipuler des documents à partir de modèles dynamiques de données et de présentation pour en faire différentes fusions ou l'adaptation aux formats d'entrée de différents outils.

La puissance du moteur de modèles dépend aussi largement de sa puissance expressive, c'est à dire du type de transformation applicable qui doit aller au delà de la simple substitution de variables (par exemple capables d'effectuer du calcul et reourner le résultat de ce calcul et non l'expression elle-même (cf. par exemple {{#expr:...}} dans MediaWiki).

Je n'ai pas tout lu de ton code, je me demande s'il est extensible pour supporter ces extensions expressives, y compris le traitement conditionnel (de type {{#if:}} ou {{#switch:}} en Mediawiki de base), les boucles de longueur variable à condition de terminaison dynamique et la gestion dynamique de variables d'état locales (non supportées dans Mediawiki), ou les fusions multicritères (un domaine où MediaWiki est ectuellement très faible, notammenet pour la catégorisation et l'ajout de métadonnées suivant un nombre indéfini d'axes d'analyse de types différents éventuellement contraints par un schéma de données).

Commentaire de FaustXVI le 15/07/2009 15:53:12

Perso je viens de tlécharger l'archive et je n'ai eu aucun probleme. Je te l'envoie par mail si tu veux.