<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Commentaires sur : Dites non a Smarty</title>
	<atom:link href="http://www.m4d3l-network.com/developpement/php/dites-non-a-smarty/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.m4d3l-network.com/developpement/php/dites-non-a-smarty/</link>
	<description>Sky is NOT the limit!</description>
	<lastBuildDate>Thu, 09 Feb 2012 22:01:21 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>Par : Spout</title>
		<link>http://www.m4d3l-network.com/developpement/php/dites-non-a-smarty/comment-page-1/#comment-1567</link>
		<dc:creator>Spout</dc:creator>
		<pubDate>Tue, 20 Jul 2010 09:01:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.m4d3l-network.com/?p=304#comment-1567</guid>
		<description>A l&#039;époque j&#039;ai voulu utiliser Smarty, et via le forum de Smarty je suis tombé sur cet article très intéressant:
http://www.massassi.com/php/articles/template_engines/
J&#039;ai complètement abandonné l&#039;idée de Smarty au profit de cette classe template en PHP pur.
&lt;q&gt;
In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code.
&lt;/q&gt;

Maintenant j&#039;utilise CakePHP qui a aussi un système de templates en PHP pur.</description>
		<content:encoded><![CDATA[<p>A l&#8217;époque j&#8217;ai voulu utiliser Smarty, et via le forum de Smarty je suis tombé sur cet article très intéressant:<br />
<a href="http://www.massassi.com/php/articles/template_engines/" rel="nofollow">http://www.massassi.com/php/articles/template_engines/</a><br />
J&#8217;ai complètement abandonné l&#8217;idée de Smarty au profit de cette classe template en PHP pur.<br />
<q><br />
In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code.<br />
</q></p>
<p>Maintenant j&#8217;utilise CakePHP qui a aussi un système de templates en PHP pur.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : M4d3L</title>
		<link>http://www.m4d3l-network.com/developpement/php/dites-non-a-smarty/comment-page-1/#comment-876</link>
		<dc:creator>M4d3L</dc:creator>
		<pubDate>Sat, 24 Apr 2010 02:47:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.m4d3l-network.com/?p=304#comment-876</guid>
		<description>Zend_View est un moteur de template de Zend. Tu n&#039;es pas obligé d&#039;utiliser le Framework au complet pour utiliser Zend_View. Zend_View viens retirer la couche de compilation que tu as besoin de faire pour compiler les tags spécifique de smarty. Quoi de mieux que d&#039;écrire du pur PHP dans le template? C’est beaucoup plus convivial. Et de plus, programmer les helpers (fonction ou modifier sur smarty) est beaucoup plus conviviale avec Zend_View. Je comprends très bien la notion de diviser l&#039;exécution et l&#039;affichage. 

Si vous en doutez, essayez Zend_View quelque temps. Et vous me direz après ce que vous pensez de Smarty!</description>
		<content:encoded><![CDATA[<p>Zend_View est un moteur de template de Zend. Tu n&#8217;es pas obligé d&#8217;utiliser le Framework au complet pour utiliser Zend_View. Zend_View viens retirer la couche de compilation que tu as besoin de faire pour compiler les tags spécifique de smarty. Quoi de mieux que d&#8217;écrire du pur PHP dans le template? C’est beaucoup plus convivial. Et de plus, programmer les helpers (fonction ou modifier sur smarty) est beaucoup plus conviviale avec Zend_View. Je comprends très bien la notion de diviser l&#8217;exécution et l&#8217;affichage. </p>
<p>Si vous en doutez, essayez Zend_View quelque temps. Et vous me direz après ce que vous pensez de Smarty!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : JoeBobJoe</title>
		<link>http://www.m4d3l-network.com/developpement/php/dites-non-a-smarty/comment-page-1/#comment-869</link>
		<dc:creator>JoeBobJoe</dc:creator>
		<pubDate>Fri, 23 Apr 2010 07:18:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.m4d3l-network.com/?p=304#comment-869</guid>
		<description>Je suis pas d&#039;accords avec toms, smarty s&#039;est inutile, sa prends beaucoup de place en mémoire, c&#039;est lourd à mettre en place et à débugger.</description>
		<content:encoded><![CDATA[<p>Je suis pas d&#8217;accords avec toms, smarty s&#8217;est inutile, sa prends beaucoup de place en mémoire, c&#8217;est lourd à mettre en place et à débugger.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : toms</title>
		<link>http://www.m4d3l-network.com/developpement/php/dites-non-a-smarty/comment-page-1/#comment-863</link>
		<dc:creator>toms</dc:creator>
		<pubDate>Thu, 22 Apr 2010 16:42:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.m4d3l-network.com/?p=304#comment-863</guid>
		<description>je pense qu&#039;il faut savoir utiliser un moteur de template, comprendre son fonctionnement, et de bien distinguer exécution et affichage.

Certes sans cette vision, il est dur de voir smarty comme un vrai outil.

Mais entendre dire, qu&#039;il faut choisir zend au lieu de smarty, ca me fait bien rire, comparer un gestionnaire de template contre un framework.
Comparons ce qui est comparable.

Smarty est un trés bon produit, quand l&#039;on comprend ce qui peut apporter vraiment.
Ca fait 4 ans que je développe sur smarty, j&#039;ai jamais mis un balise {php} dedans.</description>
		<content:encoded><![CDATA[<p>je pense qu&#8217;il faut savoir utiliser un moteur de template, comprendre son fonctionnement, et de bien distinguer exécution et affichage.</p>
<p>Certes sans cette vision, il est dur de voir smarty comme un vrai outil.</p>
<p>Mais entendre dire, qu&#8217;il faut choisir zend au lieu de smarty, ca me fait bien rire, comparer un gestionnaire de template contre un framework.<br />
Comparons ce qui est comparable.</p>
<p>Smarty est un trés bon produit, quand l&#8217;on comprend ce qui peut apporter vraiment.<br />
Ca fait 4 ans que je développe sur smarty, j&#8217;ai jamais mis un balise {php} dedans.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : M4d3L</title>
		<link>http://www.m4d3l-network.com/developpement/php/dites-non-a-smarty/comment-page-1/#comment-39</link>
		<dc:creator>M4d3L</dc:creator>
		<pubDate>Mon, 03 Aug 2009 14:44:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.m4d3l-network.com/?p=304#comment-39</guid>
		<description>TinyButSTrong semble être encore PHP4 si j&#039;en crois ce qui est marquer sur le site. Si vous travailler avec PHP5, il est préférable d&#039;utiliser des librairies écrite pour PHP5. 

Surtout pour ce qui est de la version 5.3 de PHP qui vien d&#039;être releaser qui a de plus en plus de différence avec PHP4.</description>
		<content:encoded><![CDATA[<p>TinyButSTrong semble être encore PHP4 si j&#8217;en crois ce qui est marquer sur le site. Si vous travailler avec PHP5, il est préférable d&#8217;utiliser des librairies écrite pour PHP5. </p>
<p>Surtout pour ce qui est de la version 5.3 de PHP qui vien d&#8217;être releaser qui a de plus en plus de différence avec PHP4.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : Skrol29</title>
		<link>http://www.m4d3l-network.com/developpement/php/dites-non-a-smarty/comment-page-1/#comment-38</link>
		<dc:creator>Skrol29</dc:creator>
		<pubDate>Mon, 03 Aug 2009 09:17:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.m4d3l-network.com/?p=304#comment-38</guid>
		<description>Bon ben comme l&#039;article dit d&#039;utiliser une alertnative putôt que de laisser tomber les moteurs de templates, c&#039;est l&#039;occasion de voius parler de TinyButSTrong.
TBS est un moteur mature, stable, rapide, et déjà très utilisé. Il est vraiment simple à mettre en place (un seul fichier) et c&#039;est le seul jusqu&#039;à aujourd&#039;hui qui permette de faire des modèles avec Dreamweaver ou tout autre éditeur visuel.
http://www.tinybutstrong.com/fr</description>
		<content:encoded><![CDATA[<p>Bon ben comme l&#8217;article dit d&#8217;utiliser une alertnative putôt que de laisser tomber les moteurs de templates, c&#8217;est l&#8217;occasion de voius parler de TinyButSTrong.<br />
TBS est un moteur mature, stable, rapide, et déjà très utilisé. Il est vraiment simple à mettre en place (un seul fichier) et c&#8217;est le seul jusqu&#8217;à aujourd&#8217;hui qui permette de faire des modèles avec Dreamweaver ou tout autre éditeur visuel.<br />
<a href="http://www.tinybutstrong.com/fr" rel="nofollow">http://www.tinybutstrong.com/fr</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : M4d3L</title>
		<link>http://www.m4d3l-network.com/developpement/php/dites-non-a-smarty/comment-page-1/#comment-36</link>
		<dc:creator>M4d3L</dc:creator>
		<pubDate>Tue, 28 Jul 2009 18:27:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.m4d3l-network.com/?p=304#comment-36</guid>
		<description>Je suis d&#039;accord seulement si vous développer vos projets directement live sans environnement de developpement. Smarty est capable d&#039;ignorer les erreur que les graphiste peuvent faire dans les templates. Sinon je ne vois vraiment pas ou sont les risques de sécurité si tous est fait dans un environnement de developpement (avec utilisation de gestionnaire de source ou backup régulier du projet) avant d&#039;être mis en ligne. Et faire du debug avec Smarty est bien moin évidant car justement a moin d&#039;une erreur fatal, il ne dit pas qu&#039;il y a une erreur. En PHP directement, s&#039;il y a une erreur, le graphiste peut le voir aussitot.

Je ne dit pas que Smarty n&#039;est pas bon. Je dis seulement qu&#039;aujourd&#039;hui, il y a de meilleur méthode et je veux vous amener a réfléchir sur le choix de votre engin de template pour vos futurs projets. Je n&#039;irai pas réecrire tous mes sites déjà faite pour retirer Smarty. Mais je ne l&#039;envisagerai plus dans mes futures projets sauf, si bien sur, mon employeur veut toujours utiliser Smarty. Mais libre a vous de l&#039;utilisé ou non.</description>
		<content:encoded><![CDATA[<p>Je suis d&#8217;accord seulement si vous développer vos projets directement live sans environnement de developpement. Smarty est capable d&#8217;ignorer les erreur que les graphiste peuvent faire dans les templates. Sinon je ne vois vraiment pas ou sont les risques de sécurité si tous est fait dans un environnement de developpement (avec utilisation de gestionnaire de source ou backup régulier du projet) avant d&#8217;être mis en ligne. Et faire du debug avec Smarty est bien moin évidant car justement a moin d&#8217;une erreur fatal, il ne dit pas qu&#8217;il y a une erreur. En PHP directement, s&#8217;il y a une erreur, le graphiste peut le voir aussitot.</p>
<p>Je ne dit pas que Smarty n&#8217;est pas bon. Je dis seulement qu&#8217;aujourd&#8217;hui, il y a de meilleur méthode et je veux vous amener a réfléchir sur le choix de votre engin de template pour vos futurs projets. Je n&#8217;irai pas réecrire tous mes sites déjà faite pour retirer Smarty. Mais je ne l&#8217;envisagerai plus dans mes futures projets sauf, si bien sur, mon employeur veut toujours utiliser Smarty. Mais libre a vous de l&#8217;utilisé ou non.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : James</title>
		<link>http://www.m4d3l-network.com/developpement/php/dites-non-a-smarty/comment-page-1/#comment-35</link>
		<dc:creator>James</dc:creator>
		<pubDate>Tue, 28 Jul 2009 07:25:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.m4d3l-network.com/?p=304#comment-35</guid>
		<description>Avec des exemples et des templates déjà existants, l&#039;apprentissage de Smarty se fait très rapidement et nos graphistes sont formés en moins de deux heures. Je persiste à dire qu&#039;autoriser un graphiste à coder du php n&#039;est pas sa vocation dans un projet. Autoriser un graphiste à coder du php décuple les risques de sécurité. Et même si les dossiers sont protégés, je peux vous faire tomber votre application avec une seule ligne de code. Tandis qu&#039;avec Smarty, les contours sont bien définis car justement Smarty est une interface faite pour les graphistes. Maintenant, libre à vous de mener vos projets d&#039;une autre manière.</description>
		<content:encoded><![CDATA[<p>Avec des exemples et des templates déjà existants, l&#8217;apprentissage de Smarty se fait très rapidement et nos graphistes sont formés en moins de deux heures. Je persiste à dire qu&#8217;autoriser un graphiste à coder du php n&#8217;est pas sa vocation dans un projet. Autoriser un graphiste à coder du php décuple les risques de sécurité. Et même si les dossiers sont protégés, je peux vous faire tomber votre application avec une seule ligne de code. Tandis qu&#8217;avec Smarty, les contours sont bien définis car justement Smarty est une interface faite pour les graphistes. Maintenant, libre à vous de mener vos projets d&#8217;une autre manière.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : M4d3L</title>
		<link>http://www.m4d3l-network.com/developpement/php/dites-non-a-smarty/comment-page-1/#comment-33</link>
		<dc:creator>M4d3L</dc:creator>
		<pubDate>Tue, 28 Jul 2009 01:15:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.m4d3l-network.com/?p=304#comment-33</guid>
		<description>Comme j&#039;ai mentionner dans mon articles, j&#039;ai longtemps utilisé Smarty avec Zend Framework. J&#039;ai encore plusieurs site qui roule avec Smarty comme engin de template.

Mais a quoi sert d&#039;apprendre un autre language au graphiste. Il n&#039;est pas plus long de leur montrer la base de la syntax php pour qu&#039;il puisse faire ce qu&#039;ils veullent autant qu&#039;avec les balises Smarty. Je ne crois pas que ce sois plus risqué coté securité de laisser le graphiste faire du PHP puisque dans la vue, il ne devrais pas y avoir d&#039;accès a la BD sauf dans les helpers qui devrais normalement etre coder par le developpeur php. Le resultat final devra de toutes façon être valider par un developpeur PHP avant la mise en production.

De plus, avec Zend_View, il ont normalement accès strictement au variable qu&#039;il ont besoin d&#039;acceder pour la vue qu&#039;ils sont en train de créer. Et vos graphiste un peu plus connaissant de php vont avoir beaucoup plus de liberté pour créer leur design sans avoir a faire appelle au developpeur php pour qu&#039;il ajoute d&#039;autre plugin ou autre api.

Sous php, c&#039;était nécessaire. Sous PHP5, ce ne l&#039;est plus. 

Je suis d&#039;accord sur le fait que le graphiste ne dois pas avoir les accès développeur. Mais il n&#039;est pas nécessaire de leur donner les accès développeurs au graphiste pour qu&#039;il puisse faire les vue avec du PHP. Le graphiste devrait avoir accès qu&#039;au dossier de vue et non au projet entier.</description>
		<content:encoded><![CDATA[<p>Comme j&#8217;ai mentionner dans mon articles, j&#8217;ai longtemps utilisé Smarty avec Zend Framework. J&#8217;ai encore plusieurs site qui roule avec Smarty comme engin de template.</p>
<p>Mais a quoi sert d&#8217;apprendre un autre language au graphiste. Il n&#8217;est pas plus long de leur montrer la base de la syntax php pour qu&#8217;il puisse faire ce qu&#8217;ils veullent autant qu&#8217;avec les balises Smarty. Je ne crois pas que ce sois plus risqué coté securité de laisser le graphiste faire du PHP puisque dans la vue, il ne devrais pas y avoir d&#8217;accès a la BD sauf dans les helpers qui devrais normalement etre coder par le developpeur php. Le resultat final devra de toutes façon être valider par un developpeur PHP avant la mise en production.</p>
<p>De plus, avec Zend_View, il ont normalement accès strictement au variable qu&#8217;il ont besoin d&#8217;acceder pour la vue qu&#8217;ils sont en train de créer. Et vos graphiste un peu plus connaissant de php vont avoir beaucoup plus de liberté pour créer leur design sans avoir a faire appelle au developpeur php pour qu&#8217;il ajoute d&#8217;autre plugin ou autre api.</p>
<p>Sous php, c&#8217;était nécessaire. Sous PHP5, ce ne l&#8217;est plus. </p>
<p>Je suis d&#8217;accord sur le fait que le graphiste ne dois pas avoir les accès développeur. Mais il n&#8217;est pas nécessaire de leur donner les accès développeurs au graphiste pour qu&#8217;il puisse faire les vue avec du PHP. Le graphiste devrait avoir accès qu&#8217;au dossier de vue et non au projet entier.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : James</title>
		<link>http://www.m4d3l-network.com/developpement/php/dites-non-a-smarty/comment-page-1/#comment-32</link>
		<dc:creator>James</dc:creator>
		<pubDate>Mon, 27 Jul 2009 21:11:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.m4d3l-network.com/?p=304#comment-32</guid>
		<description>Je suis chef de projet et nous utilisons ZF avec Smarty. Le plus gros avantage de Smarty, c&#039;est que les graphistes peuvent travailler tranquillement sur les templates et les css sans avoir à connaître le langage php. De plus, le fait d&#039;autoriser aux graphistes d&#039;utiliser du code php dans un projet me semble très très limite question sécurité, un graphiste n&#039;est pas un développeur et ne doit pas avoir les privilèges d&#039;accès d&#039;un développeur dans un projet bien organisé. De plus, Smarty peut être intégré facilement à Zend, nous utilisons par exemple très facilement et sans aucun problème les helpers du Zend avec Smarty. Et Smarty est facilement extensible tout simplement en assignant des objets sous forme d&#039;api, sans besoin de créer des plugins ou d&#039;autoriser la balise {php}. Je pense donc tout comme Philippe que Smarty a encore de beaux jours devant lui...qui plus est la version 3 sera 100% php5</description>
		<content:encoded><![CDATA[<p>Je suis chef de projet et nous utilisons ZF avec Smarty. Le plus gros avantage de Smarty, c&#8217;est que les graphistes peuvent travailler tranquillement sur les templates et les css sans avoir à connaître le langage php. De plus, le fait d&#8217;autoriser aux graphistes d&#8217;utiliser du code php dans un projet me semble très très limite question sécurité, un graphiste n&#8217;est pas un développeur et ne doit pas avoir les privilèges d&#8217;accès d&#8217;un développeur dans un projet bien organisé. De plus, Smarty peut être intégré facilement à Zend, nous utilisons par exemple très facilement et sans aucun problème les helpers du Zend avec Smarty. Et Smarty est facilement extensible tout simplement en assignant des objets sous forme d&#8217;api, sans besoin de créer des plugins ou d&#8217;autoriser la balise {php}. Je pense donc tout comme Philippe que Smarty a encore de beaux jours devant lui&#8230;qui plus est la version 3 sera 100% php5</p>
]]></content:encoded>
	</item>
</channel>
</rss>

