smarty/docs/fr/programmers/api-variables.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision$ -->
    <chapter id="api.variables">
     <title>Variables</title>

     <sect1 id="variable.template.dir">
      <title>$template_dir</title>
      <para>
      C'est le nom par défaut du répertoire des templates.
      Si vous ne spécifiez aucun chemin lors de l'utilisation de templates, Smarty
      les cherchera a cet emplacement.
      Par défaut, il s'agit de "./templates", ce qui signifie
      qu'il va chercher le répertoire templates
      dans le répertoire oú se trouve le script PHP en cours d'exécution.
      </para>

	   <note>
		   <title>Note technique</title>
         <para>
         Il n'est pas conseillé de mettre ce répertoire
         dans l'arborescence Web.
         </para>
	  </note>
     </sect1>		
     <sect1 id="variable.compile.dir">
      <title>$compile_dir</title>
      <para>
      C'est le nom du répertoire oú se trouvent les templates
      compilés. Par défaut, il s'agit de "./templates_c",
      ce qui signifie que Smarty va chercher ce répertoire
      dans le même répertoire que le script PHP en cours d'exécution.
      </para>
	 <note>
	 <title>Note technique</title>
	 <para>
	 Ce réglage doit être soit un chemin absolu, soit un chemin
	 relatif. include_path n'est pas utilisé pour écrire des fichiers.
	 </para>
	 </note>
	 <note>
	 <title>Note technique</title>
	 <para>
	 Il n'est pas conseillé de mettre ce répertoire
    sous la racine de l'arborescence Web.
	 </para>
	 </note>
     </sect1>
     <sect1 id="variable.config.dir">
      <title>$config_dir</title>
      <para>
      Il s'agit du répertoire utilisé pour stocker les
      fichiers de configuration utilisés dans les templates.
      La valeur par défaut est "./configs", ce qui signifie
      que Smarty va chercher ce répertoire
      dans le même répertoire que le script PHP qui s'exécute.
      </para>
	 <note>
	 <title>Note technique</title>
	 <para>
       Il n'est pas conseillé de mettre ce répertoire
      sous la racine de l'arborescence Web.
    </para>
	 </note>
     </sect1>
     <sect1 id="variable.plugins.dir">
      <title>$plugins_dir</title>
      <para>
      Ce sont les répertoire dans lesquels Smarty ira chercher les plugins
      dont il a besoin. La valeur par défaut est "plugins" sous le
      répertoire SMARTY_DIR. Si vous donnez un chemin relatif, Smarty
      regardera d'abord relativement au SMARTY_DIR, puis relativement au rtc (répertoire
      de travail courant), puis relativement a chaque entrée de votre répertoire
      d'inclusion PHP.
      </para>
	  <note>
	  <title>Note technique</title>
	  <para>
	  Pour des raisons de performances, ne réglez pas votre plugins_dir
	  pour qu'il utilise votre include_path PHP. Utilisez un
	  chemin absolu ou un chemin relatif a SMARTY_DIR ou au rtc.
	  </para>
	  </note>
     </sect1>
     <sect1 id="variable.debugging">
      <title>$debugging</title>
      <para>
      Cela active la
      <link
        linkend="chapter.debugging.console">console de débogage</link>.
      La console est une fenêtre javascript qui vous informe des templates
      inclus et des variables assignées dans la page courante.
      </para>
     </sect1>
     <sect1 id="variable.debug.tpl">
      <title>$debug_tpl</title>
      <para>
      C'est le nom du fichier template utilisé pour la
      console de débuggage. Par défaut debug.tpl, il se situe dans <link
	   linkend="constant.smarty.dir">SMARTY_DIR</link>
      </para>
     </sect1>
     <sect1 id="variable.debugging.ctrl">
      <title>$debugging_ctrl</title>
      <para>
      Cela permet d'avoir différents moyens pour activer
      le débogage. URL signifie que si SMARTY_DEBUG se
      trouve dans QUERY_STRING, le débuggage
      est activé a l'invocation du script. Si $debugging
      est a vrai, cette valeur est sans effet.
      </para>
     </sect1>
     <sect1 id="variable.global.assign">
      <title>$global_assign</title>
      <para>
      C'est une liste de variable qui sont toujours
      implicitement assignées au moteur de templates.
      Ceci est commode pour rendre des variables globales
      ou des variables du serveur accessibles a tous les templates
      plut(t que de devoir les assigner a la main. Chaque élément
      de $global_assign doit être soit le nom de la variable
      globale, soit une paire clef/valeur, oú clef est le
      nom du tableau global et valeur le tableau de variable
      assignées depuis ce tableau global.
      $SCRIPT_NAME est globalement assigné par défaut depuis
      $HTTP_SERVER_VARS.
      </para>
	 <note>
	 <title>Note technique</title>
	 <para>
	 On peut accéder aux variables du serveur avec la variable
	 $smarty, par exemple {$smarty.server.SCRIPT_NAME}.
	 Se reporter a la section sur la variable
	 <link linkend="language.variables.smarty">$smarty</link>.
	 </para>
	 </note>
     </sect1>
     <sect1 id="variable.undefined">
      <title>$undefined</title>
      <para>
      Cela régle la valeur de $undefined, null par défaut.
      N'est actuellement utilisé que pour initialiser
      des variables non-définies dans $global_assign a des
      valeurs par défaut.
      </para>
     </sect1>
     <sect1 id="variable.autoload.filters">
      <title>$autoload_filters</title>
      <para>
      Si vous désirez charger des filtres a chaque invocation
      de templates, vous pouvez le spécifier en utilisant cette
      variable. Les types de filtres et les valeurs sont des
      tableaux comportant le nom des filtres.
       <informalexample>
        <programlisting>
$smarty-&gt;autoload_filters = array('pre' =&gt; array('trim', 'stamp'),
                                  'output' => array('convert')); 
        </programlisting>
       </informalexample> 
      </para>
     </sect1>
     <sect1 id="variable.compile.check">
      <title>$compile_check</title>
      <para>
      A chaque invocation de l'application PHP, Smarty fait
      un test pour voir si le template courant a été modifié
      (date de derniére modification différente) depuis sa
      derniére compilation. S'il a changé, le template est recompilé.
      Si le template n'a pas encore été compilé, il le sera
      quelle que soit la valeur ce réglage.
      Par défaut cette valeur est a vrai. Quand
      une application est mise en production (les templates
      ne changent plus), cette vérification n'est pas nécessaire.
      Assurez-vous de mettre $compile_check a "false" pour des performances
      maximales. Notez que si vous mettez ce paramétre a "false" et qu'un
      template est modifié, vous ne verrez *pas* le changement
      car le template ne sera *pas* recompilé. Si le processus de cache
      est activé et que $compile_check l'est aussi, alors les fichiers
      du cache seront regénérés si un template concerné ou un fichier de
      configuration concerné est modifié. Voir aussi <link
	   linkend="variable.force.compile">$force_compile</link> ou <link
	   linkend="api.clear.compiled.tpl">clear_compiled_tpl</link>.
      </para>

     </sect1>
     <sect1 id="variable.force.compile">
      <title>$force_compile</title>
      <para>
      Cela oblige Smarty a (re)compiler les templates a chaque
      invocation. Ce réglage supplante $compile_check. Par défaut, il
      est désactivé. Ceci est commode pour le développement et le
      débogage mais ne devrait jamais être utilisé dans un environnment
      de production. Si le systéme de cache est actif, les
      fichiers du cache seront regénérés a chaque appel.
      </para>
     </sect1>
     <sect1 id="variable.caching">
      <title>$caching</title>
      <para>
      Ce paramétre demande a Smarty de mettre ou non en cache la sortie des
      templates.
      Par défaut ce réglage est a 0 (désactivé). Si vos templates
      générent du contenu redondant, il est conseillé d'activer le
      cache. Cela permettra un gain de performance conséquent.
      Vous pouvez aussi avoir de nombreux fichiers de cache pour un même template.
      Une valeur de 1 ou 2 active le cache. 1 indique a Smarty d'utiliser
      la variable $cache_lifetime pour déterminer si le fichier de cache a expiré.
      Une valeur de 2 indique a Smarty d'utiliser la valeur
      $cache_lifetime spécifiée a la génération du cache. Ainsi vous pouvez régler
      la durée de vie d'un fichier de cache avant de récupérer le template pour avoir
      un certain contr(le quand ce fichier en particulier expire. Voir
      aussi <link linkend="api.is.cached">is_cached</link>.
      </para>
      <para>
      Si $compile_check est actif, le contenu du cache sera regénéré
      si un des templates ou un des fichiers de configuration qui fait partie
      de ce fichier de cache a été modifié. Si $force_compile est actif, le contenu
      du cache est toujours regénéré.
      </para>
     </sect1>
     <sect1 id="variable.cache.dir">
      <title>$cache_dir</title>
      <para>
      Il s'agit du nom du répertoire oú les caches des templates
      sont stockés. Par défaut il s'agit de "./cache", ce qui signifie
      que Smarty va chercher ce répertoire
      dans le même répertoire que le script PHP en cours d'exécution.
      </para>
	 <note>
	 <title>Note technique</title>
	 <para>
       Ce réglage doit être soit un chemin absolu, soit un chemin
	 relatif. include_path n'a aucune influence lors de l'écriture des fichiers.
      </para>
	  </note>
	  <note>
		  <title>Note technique</title>
		  <para>
         Il n'est pas conseillé de mettre ce répertoire
         dans l'arborescence Web.
    	  </para>
	  </note>
     </sect1>
     <sect1 id="variable.cache.lifetime">
      <title>$cache_lifetime</title>
      <para>
      Il s'agit de la durée en secondes pendant laquelle un cache de template
      est valide. Une fois cette durée dépassée, le cache est regénéré.
      $caching doit être a "true" pour que $cache_lifetime ait une
      quelconque utilité. Avec une valeur de -1, le cache n'expire jamais.
      Avec une valeur de 0, le cache est toujours regénéré (utile
      a des fins de tests seulement. Une meilleure faton de désactiver
      le cache est de mettre <link
	   linkend="variable.caching">$caching</link> a "false").
      </para>
      <para>
      Si <link linkend="variable.force.compile">$force_compile</link> est
      activé, les fichiers du cache seront regénérés a chaque fois,
      désactivant ainsi le cache. Vous pouvez effacer tous les fichiers du cache
      avec la function
      <link linkend="api.clear.all.cache">clear_all_cache()</link>
      ou de faton individuelle (ou groupée)
      avec la fonction <link
	   linkend="api.clear.cache">clear_cache()</link>.
      </para>
	  <note>
	  <title>Note technique</title>
	  <para>
	  Si vous souhaitez donner a certains templates leur propre durée de vie
	  en cache, vous pouvez le faire en réglant
	  <link linkend="variable.caching">$caching</link> a 2,
	  puis $cache_lifetime a une unique valeur juste avant d'appeler
	  display ou fetch().
	  </para>
	  </note>
     </sect1>
     <sect1 id="variable.cache.handler.func">
      <title>$cache_handler_func</title>
      <para>
      Vous pouvez utiliser votre propre fonction de gestion du cache plut(t que
      d'utiliser celle livrée avec Smarty.
      Référez-vous a la section sur la fonction de gestion de cache
      personnalisée pour plus de détails.
      </para>
     </sect1>
     <sect1 id="variable.cache.modified.check">
      <title>$cache_modified_check</title>
      <para>
      Si cette variable est a vrai, Smarty respectera l'en-tête
      If-Modified-Since envoyé par le client. Si la date de derniére
      modification du fichier de cache n'a pas changé depuis la derniére
      visite, alors un en-tête "304 Not Modified" sera envoyé a la place
      du contenu. Cela ne fonctionne qu'avec du contenu mis en cache hors de la
      balise <command>insert</command>.
      </para>
     </sect1>
     <sect1 id="variable.config.overwrite">
      <title>$config_overwrite</title>
      <para>
      Si cette variable est a vrai, les variables lues dans les fichiers
      de configuration peuvent s'écraser entre elles. Sinon les variables
      seront mises dans un tableau. Très utile si vous voulez stocker
      des tableaux de données dans des fichiers de configuration, listez
      simplement chaque élément plusieurs fois. Mise a faux par défaut.
      </para>
     </sect1>
     <sect1 id="variable.config.booleanize">
      <title>$config_booleanize</title>
      <para>
      Si cette variable est a vrai, les valeurs on/true/yes et off/false/no
      dans les fichiers de configuration sont automitiquement converties
      en booléen. De cette faton vous pouvez utiliser ces valeurs dans le
      template de la faton suivante : {if #foobar#} ... {/if}. Si foobar
      est a on, true ou yes, l'instruction {if} sera exécutée. vrai
      par défaut.
      </para>
     </sect1>
     <sect1 id="variable.config.read.hidden">
      <title>$config_read_hidden</title>
      <para>
      Si cette variable est a vrai, les sections cachés (dont les noms
      commencent par un point) dans les fichiers de configuration peuvent
      être lues depuis les templates. On laisse habituellement cela a faux, de
      cette faton vous pouvez stocker des données sensibles dans les fichiers
      de configuration, comme par exemple des paramétres de base de données,
      sans vous soucier de la faton dont les templates les chargent.
      Mise a faux par défaut.
      </para>
     </sect1>
     <sect1 id="variable.config.fix.newlines">
      <title>$config_fix_newlines</title>
      <para>
      Si cette variable est mise a vrai, les caractéres de nouvelles lignes mac et dos
      (\r et \r\n) sont convertis en \n quand ils sont analysés. vrai par défaut.
      </para>
     </sect1>
     <sect1 id="variable.default.template.handler.func">
      <title>$default_template_handler_func</title>
      <para>
      Cette fonction est appelée quand un template ne peut pas être
      obtenu avec sa ressource.
      </para>
     </sect1>
     <sect1 id="variable.php.handling">
      <title>$php_handling</title>
      <para>
      Indique a Smarty comment interpréter le code PHP
      intégré dans les templates. Il y a quatre valeurs possibles, par
      défaut SMARTY_PHP_PASSTHRU. Notez que cela n'affecte PAS le code
      PHP entouré des balises
      <link linkend="language.function.php">{php}{/php}</link>
      dans le template.
      </para>
      <itemizedlist>
       <listitem><para>SMARTY_PHP_PASSTHRU - Smarty écrit les balises
       telles quelles.</para></listitem>
       <listitem><para>SMARTY_PHP_QUOTE - Smarty transforme les balises
       en entités HTML.</para></listitem>
       <listitem><para>SMARTY_PHP_REMOVE - Smarty supprime les balises
       des templates.</para></listitem>
       <listitem><para>SMARTY_PHP_ALLOW - Smarty exécute les balises
       comme du code PHP.</para></listitem>
      </itemizedlist>
      <para>
      NOTE : Intégrer du code PHP dans les templates est vivement
      déconseillé. Préférez les
      <link linkend="language.custom.functions">fonctions utilisateurs</link>
      ou les <link linkend="language.modifiers">modificateurs de variables</link>.
      </para>
     </sect1>
     <sect1 id="variable.security">
      <title>$security</title>
      <para>
      Cette variable est a faux par défaut. $security est de rigueur
      quand vous n'Otes pas complétement svr des personnes qui éditent les templates
      (par ftp par exemple) et que vous voulez réduire le risque que
      la sécurité du systéme soit compromise par le language de template.
      Activer cette option de sécurité applique les régles suivantes
      au langage de template, a moins que $security_settings ne spécifie
      le contraire :
      </para>
      <itemizedlist>
       <listitem><para>Si $php_handling est réglée a SMARTY_PHP_ALLOW,
         cela est implicitement changé a SMARTY_PHP_PASSTHRU.</para></listitem>
       <listitem><para>Les fonctions PHP ne sont pas autorisées dans les
         instructions IF, a part celles déclarées dans
         $security_settings.</para></listitem>
       <listitem><para>Les templates ne peuvent être inclus que depuis
         des répertoires listés dans le tableau $security_dir.</para></listitem>
       <listitem><para>Les fichiers locaux ne peuvent être récupérés que depuis
         les répertoires listés dans le tableau $security_dir en
         utilisant {fetch}.</para></listitem>
       <listitem><para>Les balises {php}{/php} ne sont pas autorisées.</para></listitem>
       <listitem><para>Les fonctions PHP ne sont pas autorisées en tant
         modificateurs, a part celles spécifiées dans $security_settings.</para></listitem>
      </itemizedlist>
     </sect1>
     <sect1 id="variable.secure.dir">
      <title>$secure_dir</title>
      <para>
      Il s'agit d'un tableau contenant tous les répertoires locaux qui sont
      considérés comme sécurisés. {include} et {fetch} l'utilisent quand
      la sécurité est activée.
      </para>
     </sect1>
     <sect1 id="variable.security.settings">
      <title>$security_settings</title>
      <para>
      Ces réglages servent à écraser ou spécifier les paramétres de sécurité
      quand celle-ci est activée. Les réglages possibles sont les suivants :
      </para>
      <itemizedlist>
       <listitem><para>PHP_HANDLING - true/false. Si vrai, le
       réglage $php_handling n'est pas vérifié.</para></listitem>
       <listitem><para>IF_FUNCS - Le tableau des noms de fonctions
       PHP autorisées dans les intructions IF.</para></listitem>
       <listitem><para>INCLUDE_ANY - true/false. Si vrai,
       les templates peuvent être inclus de n'importe oú, quelque soit
       le contenu de $secure_dir.</para></listitem>
       <listitem><para>PHP_TAGS - true/false. Si vrai,
       les balises {php}{/php} sont autorisées dans les templates.</para></listitem>
       <listitem><para>MODIFIER_FUNCS - Le tableau des noms de fonctions
       autorisées a être utilisées comme modificateurs de variables.</para></listitem>
      </itemizedlist>
     </sect1>
     <sect1 id="variable.trusted.dir">
      <title>$trusted_dir</title>
      <para>
      $trusted_dir n'est utilisée lorsque $security est activée. C'est un
      tableau de tous les répertoires qui peuvent être considérés comme svrs.
      Les répertoires svrs sont ceux qui contiennent des scripts PHP qui
      sont exécutés directement depuis les templates avec
      <link linkend="language.function.include.php">{include_php}</link>.
      </para>
     </sect1>
     <sect1 id="variable.left.delimiter">
      <title>$left_delimiter</title>
      <para>
      Il s'agit du délimiteur gauche utilisé par le moteur de templates. La
      valeur par défaut est "{".
      </para>
     </sect1>
     <sect1 id="variable.right.delimiter">
      <title>$right_delimiter</title>
      <para>
      Il s'agit du délimiteur droit utilisé par le moteur de templates.
      La valeur par défaut est "}".
      </para>
     </sect1>
     <sect1 id="variable.compiler.class">
      <title>$compiler_class</title>
      <para>
      Spécifie le nom de la classe du compilateur qui va être utilisée pour
      compiler les templates. Le compilateur par défaut est
      'Smarty_Compiler'. Réservé aux utilisateurs avancés.
      </para>
     </sect1>
     <sect1 id="variable.request.vars.order">
      <title>$request_vars_order</title>
      <para>
      L'ordre dans lequel les variables de requêtes sont enregistrées,
      identique a variables_order dans php.ini.
      </para>
     </sect1>
     <sect1 id="variable.compile.id">
      <title>$compile_id</title>
      <para>
      Identifiant persistant du compilateur. On peut passer le même compile_id
      a chaque appel de fonction mais une alternative consiste a régler ce
      compile_id, qui sera utilisé implicitement.
      </para>
     </sect1>
     <sect1 id="variable.use.sub.dirs">
      <title>$use_sub_dirs</title>
      <para>
      Régler cela a faux si votre environnement PHP n'autorise pas Smarty a créer
      des sous-répertoires. Les sous-répertoires sont efficaces, utilisez-les quand
      vous le pouvez.
      </para>
     </sect1>
     <sect1 id="variable.default.modifiers">
      <title>$default_modifiers</title>
      <para>
      Il s'agit d'un tableau de modificateurs utilisé pour assigner
      une valeur par défaut a chaque variable dans un template.
      Par exemple, pour par défaut échapper les caractéres HTML de chaque variable,
      utilisez array('escape:"htmlall"'); Pour rendre une variable indépendante
      des modificateurs par défaut, passez-lui en paramétre le modificateur
      "nodefaults" : {$var|nodefaults}.
      </para>
     </sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"../../../../manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->