[PHP4] MOTEUR DE TEMPLATE
cs_jean84
Messages postés
449
Date d'inscription
jeudi 26 août 2004
Statut
Membre
Dernière intervention
5 mars 2009
-
19 août 2006 à 23:24
cs_jean84 Messages postés 449 Date d'inscription jeudi 26 août 2004 Statut Membre Dernière intervention 5 mars 2009 - 29 août 2006 à 15:18
cs_jean84 Messages postés 449 Date d'inscription jeudi 26 août 2004 Statut Membre Dernière intervention 5 mars 2009 - 29 août 2006 à 15:18
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/39186-php4-moteur-de-template
https://codes-sources.commentcamarche.net/source/39186-php4-moteur-de-template
29 août 2006 à 15:18
@++
28 août 2006 à 18:19
28 août 2006 à 14:42
Si vous pouviez me dire ce que vous en pensez sa serait cool merci :-)
(pensez a la note sa fait toujours plaisir)
27 août 2006 à 20:58
A propos de la mise en cache des blocks (reponse pour kankrelune) j'ai fini de l'implementer ce week-end.. j'ai encore ma cle usb donc je la met en ligne des demain je pense (si j'ai aps encore oublie :p)
Merci a tous !
27 août 2006 à 12:35
27 août 2006 à 12:22
26 août 2006 à 20:39
y apprend plein de choses :-)
On devrait créer un TOP10 des commentaires sur phpcs :-)
26 août 2006 à 20:25
^_^
@ tchaOo°
ps : t'inquiète pas le boulet c'est celui qui ne cherche pas à comprendre... .. . ;o)
25 août 2006 à 14:48
Est-ce que j'ai compris ??
24 août 2006 à 15:13
$this->ContenuModele[$templateName] = $templateContent;
Ainsi dans tes méthodes tu appel le bon template en fonction du nom que lui as donné... ou via un attribut $this->lastTemplateName
Ca te permet de travailler sur plusieurs templates en parallèle dans la même instance de ta class... .. .
;o)
@ tchaOo°
24 août 2006 à 15:08
Pas de p... concernant la mise en cache c'est pas compliqué... quand tu formate ton template tu optiens du code html... des fois le template en question à un contenu statique qui n'est pas régulièrement mis à jour... genre bloc avec un texte de bienvenue en page d'acceuil... d'où l'interet pour ce genre de bloc de sauvegarder le contenu dans un fichier html qui sera repris pour un prochain affichage évitant ainsi de réouvrir le fichier template pour en récupérer le contenu, de parser les balises et de renvoyer le contenu formaté... pour ça en gros quand je sauve le fichier je le nome comme suis tmp_[nom du template hashé via md5].[timestamp de création].html... lors de l'appel de la page la class template vérifie qu'un fichier portant l'id voulue (hasch md5) existe... s'il existe la class vérifie que le fichier n'est pas trop vieux en comparant sont timestamp (+ le temps de mise en cache voulu) avec le timestamp courant si le fichier est encore d'actualité la class prend directement le contenu du fichier et arrete le traitement (pour ce template) permettant ainsi d'économiser tout le parsing couteux en perf... si la comparaison des timestamp révèle que le fichier est trop vieu celui ci est supprimé, le template original reparsé et le résultat sauvegardé dans un nouveau fichier cache... avantage un gain de perf significatif, désavantage pas grand chose il faut juste prévoir une fonction pour vider le cache (pour voir les modifications tout de suite quand tu édite ton block static et pour ne pas remplir inutilement le repertoir de cache) et bien géré le cache vis à vis des internautes... car par ex un membre qui postera un message sur un livre d'or s'il ne vois pas son message s'afficher pensera à une erreur et sera tenté de le reposter mais une fois le temps de cache passé deux message apparaitrons... .. .
par gestion multicouche j'entend deux choses... d'une part les blocs imbriqués mais ça tu l'a réglé... en effet pouvoir imbriquer des template permet de n'utiliser qu'une seule et unique instance de la class (penser à l'instanciation singleton bien pratique)... les second point c'est la gestion du cache mais pour chaques templates/block et non pas pour tout ou pour rien... .. .
Voili voilou... .. .
@ tchaOo°
24 août 2006 à 14:14
POur le moteur, sa y est il gere les blocks imbriques (les blocks dans des blocks) seul contraintes pour y arriver facilement, ferme la balise d'un block par </engine:block:nom_du_block_a_ferme>.
J'ai vire quelques die() et autres @. Je mets a jour la source des que je peux ...
@++
24 août 2006 à 13:47
Bref : c'est la définition de ton langage.
23 août 2006 à 15:57
J'ai acheter un bouquin hier, c'est XSLT fondamental... 42 ? la petite histoire quand meme... mais malgre ca, j'ai commence la lecture et c'est clair que c'est trop top !! J'ai hate que le processeur XSLT soit dispo sur une grande majorite de navigateurs, sa va etre beaucoup mieux !! par contre, il parle egalement de processeur saxon ainsi que d'un processeur mis en place par apache... il s'agirait d'un thread sur le serveur permettant la generation de code html ou rtf destine au navigateur ou a l'impression. Ayant depuis pas mal de temps envie de monter mon serveur apache pour le mettre sur le net, sais-tu ou je pourrais chopper les sources ou l'executable de cette solution ?? Et je voudrais savoir aussi a quoi sert l'espace de nommage, tu sais le <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> qui fait appelle a un fichier ou une norme (je sais plus trop) DTD... j'avoue que je me suis un peu embrouiller sur ce truc...
Pour mon bouquin, j'en suis au chapitre xpath (bien que j'ai commence a regarder le chapitre sur le focntionnement de xslt) et je dois dire WAHOU... je pensais aps que c'etait si evolue... par contre galere galere a comprendre :$ ....Au fait il parle beaucoup de java et de son api Java for XML qui permet la genreation de code egalement... as-tu des infos ??
Merci a tous !
@++
23 août 2006 à 00:27
JEAN84 expliquait :
___________________________________________________
.... mon code est utile lorsque on ne peut rajouter d'extension sur son site (genre les sites persos ou les petits hebergeurs). Mon code etait avant tout destine a ce type de service, il n'etait evidement pas destine a etre utilise sur un site pro ;-) ...
____________________________________________________
C'est effectivement comme ça que je l'ai perçu, etant debutant et heberge par free entre autre , il est evident pour moi que php5 est inaccessible , sauf en local eventuellement pour "bricoler".
Sa source est pour moi interessante car j'ai bien du mal a saisir le fonctionnement d'un template en php et celle-ci ne paraissait pas trop "grosse" a avalée , alors que le tandem xml/xlst me parait bien plus simple a mettre en oeuvre , mais limité coté client .
Sinon pour ce qui est des rendu css des navigateur, en partant d'un doctype valide html ou xhtml , on s'en sort pas trop mal , reste les vielles versions de IE (5.5 et inferieur) qui ne fond que du mode quirk, avec un peu d'habitude on arrive a eviter une majorité de bug et a l'aide des commentaires conditionnel on evite de trop titiller les "vieux" en restant sur une mise en page pas trop saccagé . Ceci dit si on vise aussi les vieux navigateur , bien souvent l'entete de la page reste un <html> de base avec le css de base aussi , dans les balise , entete ou fichier externe.
Evidemment si on veut IE5 (et d'autres) pour le xml/xlst (toujours pour rendu final (x)html ), faut passer le traitement coté serveur.
Du "coup" si il y a des tutos et/ou info qui peuvent permettre d'apprehender le "templating" a partir d'un contenu de site en xml passable a la moulinette en php 4. , je serai
tres interessé, car je me pose toujours la question de l'interet du xml et ses langage associer pour un site web , vu la "puissance" et possibilite du traitement , et surtout l'integration , l'utilisation possible des contenu "xml" dans toutes sortes d'applications.
hmm, peut-etre bien que je deborde du "sujet" et que j'aurai du aller plutot du coté du forum finalement , en tout cas je prefererait volontiers me casser la tête sur xml et CIE passer a la moulinette coté serveurs que de tenter d'apprendre et de comprendre ce qu'il faut faire pour faire un bon template .
Je suis aussi allez voir le script de anthomicro , et je dois avouez etre tres heureux d'etre tombé ici .
merci a la comunaute :)
22 août 2006 à 21:34
22 août 2006 à 21:06
22 août 2006 à 20:53
22 août 2006 à 20:50
Je compare juste le fait que quand tu dis que les perfs sont meilleures, tu compares un truc qui génère tout côté serveur face à une autre solution qui fait presque tout côté client... normal que les perfs soient meilleures. Tandis qu'en CSS si tu te débrouilles bien t'auras pas de différences entre les navigateurs. Si tu compares deux solutions équivalentes en terme de machines utilisées pour le rendu (à savoir que le serveur ou que le client ou les deux mais dans les mêmes proportions) je mets ma queue à couper que les templates gérées avec une classe optimisées sont plus performantes que n'importe quelle solution de parsing XML + XSLT :)
22 août 2006 à 18:21
et ensuite : ben nan...php génère du html, qui, couplé à des css, affiche COTE CLIENT quelquechose...qui est différent selon les clients. La preuve...le box model d'IE est différent du box model de FF, nan? Enfin, un moteur de template ne change rien à ça : c'est côté client que l'affichage se fait, toujours! Que ce soit du html, du xhtml, des css, du xml, ou du xhtml généré à partir de xml via xslt...c'est kif kif tout ça.
22 août 2006 à 17:54
C'est pour ça qu'il ne peut rivaliser en terme de perfs c'est ce que je disais plus haut, c'est un truc lourdingue ;)
Après XSLT coté client je trouve pas ça propre car ça déplace le problème, le rendu peut ne pas être le même comme tu l'as souligné, contrairement au rendu côté serveur, et dès que y'a du rendu côté serveur, les perfs d'un bon système de templates sont meilleures ;)
22 août 2006 à 16:09
JEAN84 = > ok, pas de problème, on arrête la guéguerre ;-)
XSL est un ensemble de "modules". On y trouve notamment XSLT, XSL-FO...ou XPATH.
http://www.w3.org/Style/XSL/
Pour schématiser, j'ai repris le code d'Antho, et plus exactement son exemple de template html, pour en faire une version XML/XSLT. Sachant évidemment que dans un vrai moteuyr basé là-dessus, il faudra générer de toutes façons donner les bonnes valeurs au flux XML (là, je l'ai fait en dur)
.
fichier template.xml (qui vaut pour l'instanciation de l'objet template et l'assignation de ses propriétés):
<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet type="text/xsl" href="template.xsl"?>
<TEMPLATE>
<HEAD>
<TITRE>Mon Titre</TITRE>
<DESCRIPTION>Ma description</DESCRIPTION>
<KEYWORDS>mot1;mot2</KEYWORDS>
</HEAD>
Bonjour Moi
<DATE>22-08-2006</DATE>
Bienvenue Moi
</TEMPLATE>
Le fichier template.xsl qui fait la transormation en XHTML (quyi vaut pour le fichier html template, dans un moteur de template) :
<?xml version ="1.0" encoding ="iso-8859-1" ?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output
method="html"
encoding="ISO-8859-1"
doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"
doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
indent="yes" />
<xsl:template match="TEMPLATE">
<head>
<xsl:apply-templates select="HEAD" />
</head>
<xsl:apply-templates select="BODY" />
</xsl:template>
<xsl:template match="HEAD">
<xsl:param name="description" select="DESCRIPTION" />
<xsl:param name="keywords" select="KEYWORDS" />
<title><xsl:value-of select="TITRE"/></title>
<meta name="description" content="{$description}"/>
<meta name="keywords" content="{$keywords}"/>
</xsl:template>
<xsl:template match="BODY">
<xsl:value-of select="IDENTIFICATION"/>
<xsl:value-of select="DATE"/>
<xsl:value-of select="BIENVENUE"/>
<!--BLOC-->
<li>
<li>test</li>
</li>
<!--/BLOC-->
</xsl:template>
</xsl:stylesheet>
Si vous analysez bien, vous verrez que ce n'est pas très différent...au fond ;-)
22 août 2006 à 15:13
Merci d'avance et encore desole.
anthomicro > grand moment de solitude pour les blocks imbriques... je suis bien entrain de me battre avec mais sa me pete a la figure toutes les 3 lignes.... je mettrais la mise a jour des que j'aurais compris d'ou vient le probleme ^^
kankrelune > Pour les images, disons que c'est une de mes fantaisies persos et ce n'etait absolument pas necessaire, j'en ai bien concience... mon idee de base etait de pouvoir en fait lister les images d'un repertoire et les afficher grace au moteur. Pas vraiment utile mais l'idee m'amusait alors je me suis dit pourquoi pas ? faut bien rigoler de temps en temps ^^
Sinon pour les css clair que j'avais pas penser a sa... disons que je venais de finir pas mal d'autre trucs et que j'ai pas trop reflechis.... je modifis sa tout de suite ! et pareille pour les die() et autre @... qui sont au final inutile et ralentisse le moteur... J'ai fait un code en C++ recement et c'est vrai qu'il m'est reste quelques traits de paranoia...
Par contre la ou je ne te suis plus du tout, c'est quand tu parle de template multi couches et de mise en cache... si tu pouvais m'eclairer... ! sa serait sympa merci :-)
FhX > entierement d'accord avec toi... je l'ai compris au moment meme ou je le codais mais malheureusement, la mise a jour vers php5 de tout le parc des hebergeurs n'est pas pour tout de suite !! Si je fais un code de ce genre c'est plus pour l'utiliser dans mes creations plutot que de le laisser moisir dans un dossier... et pour ne citer que les principaux hebergeurs gratuits (genre free, lycos, ifrance ect et meme hosteur qui est mon hebergeur payant), ils sont tous dans la majorites en php4 ! Je ne tente pas de generaliser et il est certains que des hebergeurs commencent a proposer le 5 mais malgre cela, je trouve (c'est un avis perso) qu'il est encore penible et peu evident de trouver un hebergeur respectable faisant tourne cette version de php. Ce n'est evidement que mon avis !!
@++
22 août 2006 à 14:42
Le langage serveur est dédié aux traitements côté serveur SANS AUCUN LIEN avec le templating : accès aux bases de données, calculs complexes etc etc...et c'est XSLT qui se charge de mettre les résultats dans le XML.
Bref, mon idée : un moteur de template uniquement en XML/XSLT. Et inutile de le développer, il existe déjà : c'est XSLT ;-)
Et ça, franchement, je ne pense pas qu'un moteur de template PHP puisse le battre XML/XSLT (côté client donc) en terme de rapidité.
Après, vient le problème de base : les moteurs client XSLT ne sont pas toujours encore très performants. Mais ça viendra, et ça s'améliore de jour en jour d'ailleurs (ou presque lol).
22 août 2006 à 13:53
Après rien ne vaut un test :) Mais bon déjà en général ces trucs là ce sont des usines à gaz donc bon je me fais pas d'illusions quant aux perfs sans cache ;)
22 août 2006 à 13:32
Enfin je dis ca parce que moi j'ai évolué très vite en PHP5 aussi...
Mais c'est vrai que je préfèrerai à la limite utiliser XML/XSLT pour faire du template plutot que PHP.
Faire du remplacement de variable pour un affichage n'est pas ce qui fait de mieux pour PHP... autant lui dédier d'autres taches comme de la récupération d'infos ou du calcul.
Après chacun son choix.
22 août 2006 à 12:43
22 août 2006 à 12:41
22 août 2006 à 09:30
Je ne vois pas en quoi ça réduirait drastiquement les perfs. En tous cas, un framework comme XMLRAD couplé à PHP, pour l'avoir testé il y a peu, n'est pas plus lent qu'un autre moteur dédié à PHP.
21 août 2006 à 18:42
Assurément, m'enfin bon pourquoi foutre la structure de ton site en xml ? le contenu à la rigueur admettons, mais la structure invariante ? je n'en vois pas l'intérêt sinon réduire les perfs ;)
21 août 2006 à 15:02
Et y a plusieurs solutions (je rappelle que je ne me suis jamais penché sur le problème vu que je n'ai jamais eu l'intention de créer un moteur de template) :
DOM+XSLT demande l'extension XSLT (vu que DOM est normalement installé par défaut).
DOM tout court ne demande rien de spécial (on peut se passer d'XSLT, évidemment, en le simulant. Et ça reste simple puisque via DOM, on a pas besoin de parser type expressions régulières du tout).
XML+XSLT tout simple (sans php) est carrément plus portable que php4, sinon, lol (et là encore, c'est toujours possible).
%ais je le répête, la base d'un tel moteur serait : une bonne réflexion sur la structure XML globale (sachant que ce sera toujours modulable), de préférence un appui XSLT pour faciliter les choses, si possible côté client, et un langage côté serveur qui sera plus chargé des traitements en amont (bref, c'est le langage côté serveur, ce serait plus pour un framework...le templating pouvant largement se contenter d'XML/XSLT. Comme le montrent quelques framework actuels, dont XMLRAD).
Quant à la rapidité, je ne suis pas convaincu du tout mais comme je l'ai dit, oui, ça demanderait un bench :-)
21 août 2006 à 14:53
Pour moi le plus gros problème est/a été de bien gérer le cache sur des templates multicouche (ex le theme du site non cachable, le block X cachable, le block Y non cachable, etc)... et bien parser les boucles et les conditions (pas encore finit)... le tout avec des perf acceptables... .. .
Sinon coté code à vu de nez...
- il faut optimiser la méthode de bbcodes les multi str_replace sont inutiles et lourd
- le @ et le or die pour le str_replace sont inutiles str_replace ne renverra jamais false ou alors faut sérieusement s'inquiéter.
- dans la methode setCss tu te prend la tête avec ta balise <engine...>
// On parcours le tableau
$nbArgs = count($Args);
$Fss = '';
for($i=0; $i<$nbArgs; $i++ )
$Fss .= '<link media="all" rel="stylesheet" type="text/css" href="'.$Args[$i].'" />';
$this->ContenuModele = str_replace('<engine:css />', $Fss, $this->ContenuModele);
Point... pas besoin d'en faire plus... au passage on ne met jamais de count() dans la définition d'une la boucle for sauf si le tableau en question est suceptible de changer de taille en cours de route car l'expression du milieu est testée (et donc le count() éxécuté) avant chaque itération... 1000 itération = 1000 count
Je trouve les multiple die un peu inutiles voir éxagéré... d'une part ce n'est normalement pas à cette class de gérer la réaction à avoir en cas d'errreur, normalement elle doit renseigner dans un attribut les erreurs point barre c'est à toi de gérer ces erreur en dehors de la class, d'autre part faire un die parce que le nom d'une variable est oublié est un peu éxagéré... si la class n'arrive pas à récupérer le contenu du fichier template passe encore (bien que ce soit plutot crade) mais pour un tags mal déclaré ou non trouvé c'est éxagéré... au pire le gars aura une balise <engine...> qui apparaitra dans sa page et corrigera l'erreur... au mieux tu peux introduire la notion (optionelle) de parsing strict et virer toutes les balises inutilisées en fin de parsing en les logguant pour savoir quels balises ne sont pas utilisées pour pouvoir modifier le template en concéquance... .. .
Voila ce qui me vient à l'esprit en regardant ton code... améliorations possible hormis une otpimisation/réécriture de certain passages du code... intégration de la mise en cache... c'est un plus non néligeable... éventuellement permettre une gestion multi template/multi block serait pas mal non plus et permettrait une utilisation en singleton (une seul instance gérant tous les templates du site)... à mon avis il serait bien de séparer la logique de déclaration des template/block/tag de leur parsing (à faire juste avant l'affichage) permettant des modifications des elements à n'importe quel moment avant l'affichage par exemple en cas d'erreur... mais ça c'est encore une fois un avis (et une façon de fonctionner) perso... .. .
Voili voilou... .. .
@ tchaOo°
21 août 2006 à 13:17
je ne sais pas si ton code gère les blocs imbriqués, le mien non mais je te le montre : http://www.vulgarisation-informatique.com/source-69--php-4-classe-de-templates-avec-systeme-de-cache.php
Concernant XML / XSLT, l'avantage d'un système de templates fait avec une classe PHP 4 est qu'il peut être plus rapide tout en étant largement plus portable ;)
Je ne demande qu'a bencher les deux solutions en ce qui me concerne, mais bon question portabilité celle-ci est largement devant étant donné que tu n'as besoin d'aucune extension pour la faire tourner ;)
21 août 2006 à 12:39
Beaucoup de gars se plaignent de ne pas avoir de commantaires, mais dès qu'ils en ont, si ce n'est pas "Ton code est génial!!", ils se vexent. Aucune envie de discuter d'un code si c'est pour que l'auteur se vexe pour rien tous les 3 mots.
Maintenant...pour te répondre :
le plus beau des moteurs de template orienté HTML, pour moi, ça reste les CSS. Mais ça ne gère que la mise en page, pas le contenu. Vouloir utiliser un moteur de tamplete pour le contenu, pourquoi pas, c'est une mode qui perdure depuis un moment déjà.
Néanmoins, je pense sincèrement que le futur est bien au XML (et XHTML2 va plus encore dans ce sens).
En effet, je parle bien, pour un moteur de template basé sur XML, de transformation XSL, de DOM, et de gestion de tout ça par PHP. Si Opera ne gère pas bien xml...bah ce n'est pas très grave puisqu'en effet, le but est de renvoyer du XHTML au navigateur. Et XSLT fait ça très bien.
Il faut bien comprendre qu'un moteur de template est déjà très lourd : ça fait du parsing à outrance, avec des expressions régulières (et autres fonctions plus rapides quand c'est possible évidemment). Et quand c'est bien fait, ça doit gérer les blocs et leur hiérarchie. Et forcément, puisqu'on gère du html, on suit le modèle DOM.
Que fait DOM (l'extension php) ? Grosso modo, la même chose : cela gère un document (XML en l'occurence), sauf que c'est en natif. L'accès à un élément se fait forcément plus rapidement via l'extension DOM que si l'on devait réécrire cet accès avec des expressions régulières.
Je n'ai pas créé de moteur de template en XML, et je ne pense pas le faire. J'ai créé de nombreux modules XML qui font peu ou prou la même chose, mais en dédié à une tâche bien précise; ceci dit, je suis prêt à parier qu'un moteur de template basé sur XML sera plus rapide qu'un moteur de template classique. Et il sera bien plus facilement portable.
Et puis, à la limite, DOM n'est même pas nécesssaire dans ce cadre : l'extension XSLTProcesor peut suffire, selon le type de moteur que l'on veut écrire. Et avec elle, ce n'est pas la navigateur qui va transformer le XML, mais le serveur. Le navigateur recevra bien son XHTML et la CSS associée.
21 août 2006 à 11:59
malalm -> dommage que tu quitte le post, ce code est interessant pour moi sous plein d'aspect (le principe du template ...et je suis un vrai debutant ) et tru semble avoir des choses interessantes a dire :)
D'un autre coté je ne comprends pas encore trop l'interet du xml/xslt dans l'utilisation d'un template pour un site .
Il me semble bien que ça ne passe pas partout, xml 1.0 pour FF et IE , mais opera en zappe une bonne partie (pour le rendue du template ).
Du coup ,
les donneés du site doivent etre generé en xml ( , passé a la moulinette par xslt , en appliquant une template, pour au resultat avoir du html (probablement qu'arrivé a ce stade on ne parlera même plus de html ou xhtml aux standard W3C par tout les efforts effectué jusqu'alors )
Et pour un rendu compatible multi-navigateur il faudrait demandé a php de gerer tout ça (avec un petit coup de "dom" en plus) et de ne renvoyé qu'au navigateur du (x)html et son css associer.
Bref, je crois que les moteur de templates (php/html) ont encore une belle vie devant eux , et cette exemple , a l'air assez "comprehensible" pour un novice comme moi . se limiter a php, html, css , n'induit qu'un langage de programmation ,
alors que xml-> xslt-> php->(x)html & css , demande a en utiliser plutot 2 et alourdirais le "traitement" ?
Ou bien je n'ai pas bien saisie les possibilité xml/xslt et CIE.
Merci et bravo encore pour la source ...
++
21 août 2006 à 08:17
décidément, les commentaires sont difficiles à faire. J'ai dit "as-tu benché"..."parce qu'à mon avis"...si encore j'avais dit : "pardonne-moi mais ton code, c'est de la merde, il rame grave", j'aurais compris ta réaction.
Commence à me fatiguer ces réactions...
T'as pas envie qu'on discute de ton code, soit, moi, je dégage de ce post.
20 août 2006 à 21:45
2/3 trucs :
Alain Proviste > Pourquoi un moteur de template ? Parce qu'on m'a demander d'en faire un et je trouve sa beaucoup plus pratique et qu'en plus, je ne connaissait que les moteurs de template et pas les templates tout cours... je vais faire une recherche pour voir
malalam > tu parles sans savoir => "Par curiosité, tu as benché ton moteur ? parce qu'à mon avis, ça doit pas mal ramer" tu pars d'une imrpession et puis tu derives vers "A mon avis, j'insiste, il rame..." ... cool sa.. et tout sa en regardant le code 10 secs ? "Je regarde pas en détail, parce que vraiment un truc me saute aux yeux : tu devrais te pencher sur son optimisation"... je suis d'accord pour l'optimisation m'enfin des commentaires dans ce genre.... et pour XML/XSLT, bah pour avoir regarder sa a l'air cool mais a ce moment la je te dirais de relire mon commentaire du debut a savoir => "Ce n'est pas le code du siecle mais sa peut toujours servir pour une premiere approche dans le cadre d'une utilisation futur d'un moteur plus pousse" ... une premiere approche ^^ simple non ? suffisait de lire !
Par contre tu vois XML/XSLT je connaissais pas et apres avoir lu un tuto dessus, je vais m'y interesse de pres ... merci pour l'info
pcgpegase > ok je te fait un exemple des que je peux
@++
20 août 2006 à 11:10
ce n'est pas ce qu'a dit Alain Proviste ;-) Il a dit qu'il était un peu dommage d'écrire un moteur de template à l'heure du PHP5; il ne t'a pas demandé pourquoi tu avais utilisé php4 pour écrire ton moteur de template. Et je suis plutôt d'accord avec lui.
Il y a de nos jours tout un tas d'autres possiblités. Ne serait-ce que simplement XML/XSLT. Un sacré moteur de template, ça...le plus puissant que je connaisse.
Par curiosité, tu as benché ton moteur ? parce qu'à mon avis, ça doit pas mal ramer : bcp d'expressions régulières quand même. Au passage, pourquoi ne pas avoir fait 1 str_replace avec des tableaux en paramètres? Je regarde pas en détail, parce que vraiment un truc me saute aux yeux : tu devrais te pencher sur son optimisation. A mon avis, j'insiste, il rame...
20 août 2006 à 03:05
En ce qui concerne ton code sympa au premier coup d'oeil. J'en avais fait un moi à partir de sources provenant de développez.com. Mais en un seul fichier bravo.
Par contre pour répondre à Alain, l'intérêt vient du faite que la quasi totalité des codes qui marchent sur Php4 vont sur Php5 et que tout le monde à le 4 alors que tout le monde n'a pas encore installé le 5. Question de compatibilité.
Pour PCGPEGASE, les templates signifie que pour un millier de pages voir plus tu vas utiliser le même modèle graphique et ergonomique de page web. Ainsi si tu veux changer la couleur de l'avant dernière case du tableau en bas à gauche tu n'as pas besoin d'ouvrir les milles pages. Juste le modèle ou template(ça veut dire patron en anglais, comme pour la couture).
Cordialement,
Xeonarno
20 août 2006 à 01:29
Je n'arrive pas à comprendre l'utilisation de cette source (sûrement parce que je ne connais pas le système de templates...), peux-tu fournir un petit peu plus d'aide ? :)
Merci !
20 août 2006 à 01:07
enfin moi je dis ça, php c'est pas ma prédilection...
19 août 2006 à 23:24
@++