le 28/10/2008 à 12:48
er-issam
Bonjour
est ce qlq1 pourez me passez un tuto de comment utiliser le module smarty
merci
est ce qlq1 pourez me passez un tuto de comment utiliser le module smarty
merci
module smarty
le 28/10/2008 à 21:02
LA GLOBULE
Ça doit se trouver sur le net je pense ce genre de trucs je pense.
Sinon, il faudrait en écrire un sur lephpfacile.
Sinon, il faudrait en écrire un sur lephpfacile.
le 31/10/2008 à 01:01
caporga
effectivement, on le trouve bien sur internet, voir lien ci-dessous, cependant je débute dans le code j'ai lu un peu, je vois pas trop l'implication et l'intérêt ( sauf pour les grosse boite de dév )... qu'en pensez vous ???
http://www.smarty.net/
http://www.smarty.net/
le 31/10/2008 à 10:04
LA GLOBULE
Si le projet existe et que des gens l'utilisent, l'intérêt doit exister.
Personnellement, je pense que PHP est déjà un moteur de template à lui seul.
PS : dans toutes les boites ou j'ai bossé (pourtant éditrices de gros sites), je n'ai jamais utilisé smarty.
Personnellement, je pense que PHP est déjà un moteur de template à lui seul.
PS : dans toutes les boites ou j'ai bossé (pourtant éditrices de gros sites), je n'ai jamais utilisé smarty.
le 01/11/2008 à 03:32
LupusMic
(caporga) L'intérêt est fondamental lorsque tu souhaite confier le design à des webdesigner plutôt qu'à des développeurs.
le 05/11/2008 à 00:26
caporga
Lupus, tu veux dire que smarty permet de générer du code... je vais vraiment aller voir ça... et je reviens vers vous...
le 06/11/2008 à 07:17
LupusMic
Ça dépend de ce que tu entends par code. Smarty part du principe que le PHP c'est trop compliqué pour les WebDesigner, qu'il y a trop d'implication liées à la sécurité pour un béotions d'utiliser PHP, car PHP a bien évolué depuis qu'il n'était qu'un langage de template (car s'en est un, mais il est parti dans tout les sens et requiert aujourd'hui une réelle expertise).
Bref, dans les templates Smarty, tu n'as qu'un ensemble (volontairement) très limité de structures logiques, l'essentiel étant l'usage de clés. Ce template sera chargé comme un fichier à parser, et ne sera pas interprété par PHP, lorsque le moteur de parsing de Smarty trouve des structures qu'il comprend, il les interprète et génère une sortie (généralement HTML). Pour ce faire, il se réfère à un objet registre qui contient les variables disponibles pour l'affichage.
Le but ultime de Smarty, c'est véritablement de découpler le modèle (les données traitées par l'application) de la vue (le HTMl par exemple).
On pourrait imaginer un moteur de template qui pourrait s'utiliser ainsi (exemple non-fonctionnel) :
Finalement, mon exemple de template ressemble plus à de l'XSL que du Smarty, mais l'idée est là.
Bref, dans les templates Smarty, tu n'as qu'un ensemble (volontairement) très limité de structures logiques, l'essentiel étant l'usage de clés. Ce template sera chargé comme un fichier à parser, et ne sera pas interprété par PHP, lorsque le moteur de parsing de Smarty trouve des structures qu'il comprend, il les interprète et génère une sortie (généralement HTML). Pour ce faire, il se réfère à un objet registre qui contient les variables disponibles pour l'affichage.
Le but ultime de Smarty, c'est véritablement de découpler le modèle (les données traitées par l'application) de la vue (le HTMl par exemple).
On pourrait imaginer un moteur de template qui pourrait s'utiliser ainsi (exemple non-fonctionnel) :
<?php
$membres = array() ;
$nembres[] = (object) array('id' => 1, 'name' => 'Lupus', 'login' => (object) array('date' => '2008 11 06 07 00')) ;
$nembres[] = (object) array('id' => 2, 'name' => 'carpoga', 'login' => (object) array('date' => '2008 11 05 22 35')) ;
$tpl =<<<EOT
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="fr">
<head>
<title>%wiz:titre;</title>
</head>
<body>
<div id='body'>
<wiz:if test="membres.length > 0">
<table>
<thead>
<tr><td>Membre</td><td>dernière connexion</td></tr>
</thead>
<tbody>
<wiz:for collection='membres' in='membre'>
<tr id='membre-%wiz:membre.id;'>
<td>%wiz:membre.name;</td>
<td>%wiz:membre.login.date;</td></tr>
</wiz:for>
</tbody>
</table>
</wiz:if>
<wiz:if test="membres.length = 0">
<p>Il n'y a pas de membres qui se sont connectés.</p>
</wiz:if>
</div>
<div id='debug'>
<wiz:if test="connected">
<p>La connection s'est bien effectuée.</p>
</wiz:if>
</div>
</body>
</html>
EOT;
// on créé le parseur à partir d'une fonction membre statique
$view = wiz::from_string($tpl) ;
// le moteur de template repère ce qu'il comprend (balises <wiz: > et entités %wiz: ;)
$view->parse() ;
$view->bind_string('title', 'La liste des membres connectés.') ;
$view->bind_array('membres', $membres) ;
$view->bind_callback('connected', 'mysql_ping') ;
/* appel de la méthode magique $wiz->__tostring. La méthode va effectuer le lien entre les données liées et les « variables » présentent dans le fichier template, et générer le code HTML correspondant.
*/
echo $view ;
Finalement, mon exemple de template ressemble plus à de l'XSL que du Smarty, mais l'idée est là.
le 06/11/2008 à 08:33
LA GLOBULE
Je vais parler de mon expérience personnelle.
En général, dans le milieu pro, tu as un designer qui fait une maquette, et ensuite, tu as un développeur qui doit coder la fonctionnalité désirée et le monteur HTML qui doit écrire le code HTML (ou le template smarty si tu utilises smarty).
Ben souvent, le monteur HTML bosse avant le développeur PHP. Celui ci découpe la maquette et il fait son montage HTML avec du texte en dur dans le HTML.
Ensuite, le développeur PHP va faire son code et remplacer ces textes en dur par des variables PHP.
Donc dans ce cas, smarty n'est que peu "utile", pour deux raisons.
1) le monteur HTML doit apprendre la syntaxe smarty
2) à cause du balisage smarty, le monteur HTML peut difficilement tester dans son navigateur la qualité de son montage
Mais on peut avoir un autre cas de figure : le développeur fait le code PHP avant que le monteur HTML monte sa page (ou tout simplement lorsque le monteur HTML doit modifier son montage alors que le code PHP est déjà écrit).
La, si tu as un site bien conçu, c'est à dire en séparant au maximum le code PHP du code HTML (moi, ce que je fais, c'est que j'ai des .php qui font des requetes SQL, qui traitent des formulaires, et ensuite, ce .php fait un require 'toto.html' et dans toto.html, je n'ai que des <?php echo $blu; ?> ou quelques if ou quelques for, mais en aucun cas des "traitements" PHP. Donc cette page HTML qui contient quand même du PHP pour afficher des données est "simple" d'accès).
Dans ce cas, en général, les monteurs HTML ne sont pas cons. Ils ont déjà vu du code PHP dans leur vie. Ils savent qu'un <?php echo $nb_result; ?> va afficher le nombre de résultat d'une recherche par exemple. Ils savent qu'un for va faire une boucle, etc.
Donc la aussi, je trouve l'intérêt de smarty limité, car le monteur HTML doit apprendre la syntaxe smarty (de même que le développeur).
Et entre un '<td>%wiz:membre.name;</td>' et un <td><?php echo $membre->name; ?></td>, je pense qu'il y'a "peu de différence".
Enfin, si, il y'en a une, dans le cas de smarty, tu as un parseur qui doit parser le template, et donc consommer du CPU.
En général, dans le milieu pro, tu as un designer qui fait une maquette, et ensuite, tu as un développeur qui doit coder la fonctionnalité désirée et le monteur HTML qui doit écrire le code HTML (ou le template smarty si tu utilises smarty).
Ben souvent, le monteur HTML bosse avant le développeur PHP. Celui ci découpe la maquette et il fait son montage HTML avec du texte en dur dans le HTML.
Ensuite, le développeur PHP va faire son code et remplacer ces textes en dur par des variables PHP.
Donc dans ce cas, smarty n'est que peu "utile", pour deux raisons.
1) le monteur HTML doit apprendre la syntaxe smarty
2) à cause du balisage smarty, le monteur HTML peut difficilement tester dans son navigateur la qualité de son montage
Mais on peut avoir un autre cas de figure : le développeur fait le code PHP avant que le monteur HTML monte sa page (ou tout simplement lorsque le monteur HTML doit modifier son montage alors que le code PHP est déjà écrit).
La, si tu as un site bien conçu, c'est à dire en séparant au maximum le code PHP du code HTML (moi, ce que je fais, c'est que j'ai des .php qui font des requetes SQL, qui traitent des formulaires, et ensuite, ce .php fait un require 'toto.html' et dans toto.html, je n'ai que des <?php echo $blu; ?> ou quelques if ou quelques for, mais en aucun cas des "traitements" PHP. Donc cette page HTML qui contient quand même du PHP pour afficher des données est "simple" d'accès).
Dans ce cas, en général, les monteurs HTML ne sont pas cons. Ils ont déjà vu du code PHP dans leur vie. Ils savent qu'un <?php echo $nb_result; ?> va afficher le nombre de résultat d'une recherche par exemple. Ils savent qu'un for va faire une boucle, etc.
Donc la aussi, je trouve l'intérêt de smarty limité, car le monteur HTML doit apprendre la syntaxe smarty (de même que le développeur).
Et entre un '<td>%wiz:membre.name;</td>' et un <td><?php echo $membre->name; ?></td>, je pense qu'il y'a "peu de différence".
Enfin, si, il y'en a une, dans le cas de smarty, tu as un parseur qui doit parser le template, et donc consommer du CPU.
le 06/11/2008 à 09:40
LupusMic
(La Globule) Je suis d'accord avec ton approche, et je l'ai aussi déjà employée. D'ailleurs, c'est ce que j'ai pour l'instant retenu dans mon logiciel de blog. Le problème, c'est que je suis paranoïaque, et que donc je vais de toute façon me diriger vers un système de template (mais en XSL par contre).
Ce qui m'embête dans ton exemple, c'est que $membre->name peut contenir du code non-échappé (au sens HTML). Alors qu'en employant un moteur de template, on peut faire en sorte que l'ensemble des données liées du modèle à la vue seront contrôlées et remie d'équerre. Alors qu'en accédant directement au modèle, il faut plus de rigueur en amont.
Finalement, c'est une question de confiance et d'approche.
(Il faut préciser que mon exemple n'a rien à voir avec Smarty, c'est uniquement une proposition d'exemple pour montrer la logique qu'il y a avec ce genre d'approche)
Quand à la consommation de CPU... ça dépend de ce qu'on veut privilégier. Mais une chose est certaine : la sécurité a un coût.
Ce qui m'embête dans ton exemple, c'est que $membre->name peut contenir du code non-échappé (au sens HTML). Alors qu'en employant un moteur de template, on peut faire en sorte que l'ensemble des données liées du modèle à la vue seront contrôlées et remie d'équerre. Alors qu'en accédant directement au modèle, il faut plus de rigueur en amont.
Finalement, c'est une question de confiance et d'approche.
(Il faut préciser que mon exemple n'a rien à voir avec Smarty, c'est uniquement une proposition d'exemple pour montrer la logique qu'il y a avec ce genre d'approche)
Quand à la consommation de CPU... ça dépend de ce qu'on veut privilégier. Mais une chose est certaine : la sécurité a un coût.
Ecrire un message
Votre message vient d'être créé avec succès.
