smarty/docs/fr/preface.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision$ -->
<!-- EN-Revision: 1.2 Maintainer: gerald Status: ready -->
<preface id="preface">
 <title>Préface</title>
 <para>
 "Comment rendre mes scripts PHP indépendants de la présentation ?".
  Voici sans doute la question la plus posée sur la mailing list
  PHP. Alors que PHP est étiqueté "langage de script
  pour HTML", on se rend vite compte, après quelques projets qui mélangent
  sans complexe HTML et PHP, que la séparation entre la forme et
  le contenu, c'est bien [TM]. De plus, dans de nombreuses entreprises
  les rôles du designer et du programmeur sont distincts. La solution template
  coule donc de source.
 </para>
 <para>
  Dans notre entreprise par exemple, le développement d'une application
  se fait de la manière suivante : une fois le cahier des charges écrit,
  le designer réalise une maquette, et donne ses interfaces
  au programmeur. Le programmeur implémente les fonctionnalités applicatives
  et utilise les maquettes pour faire des squelettes de templates. Le projet
  est alors passé au designer HTML/responsable de la mise en page qui amène les
  templates jusqu'au faîte de leur gloire. Il est possible que le projet fasse
  une fois ou deux des allers/retours entre la programmation et la présentation.
  En conséquence, il est important de disposer d'un bon système de template. Les
  programmeurs ne veulent pas avoir à faire au HTML, et ne veulent pas non plus
  que les designers HTML bidouillent le code PHP. Les designers ont besoin d'outils
  comme des fichiers de configuration, des blocs dynamiques et d'autres solutions
  pour répondre à des problématiques d'interface, mais ne veulent pas
  nécessairement avoir à faire à toutes les subtilités de la programmation PHP.
 </para>
 <para>
  Un rapide tour d'horizon des solutions type template aujourd'hui et
  l'on s'aperçoit que la plupart d'entre elles n'offrent que des moyens
  rudimentaires pour substituer des variables dans des templates, ainsi que des
  fonctionnalités limitées de blocs dynamiques. Cependant nous avons
  besoin d'un peu plus. Nous ne voulons pas que les programmeurs
  s'occupent de la présentation HTML du TOUT, mais cela est pratiquement
  inévitable. Par exemple, si un designer veut des couleurs d'arrière plan
  différentes pour alterner entre différents blocs dynamiques, il est nécessaire
  que ce dernier travaille avec le programmeur. Nous avons aussi besoin que les
  designers soient capables de travailler avec leurs propres fichiers
  de configuration pour y récupérer des variables, exploitables dans leurs
  templates. Et la liste est longue.
 </para>
 <para>
  Fin 1999, nous avons commencé à écrire une spécification pour un moteur de
  template. Une fois la spécification terminée,
  nous avons commencé à travailler sur un moteur de template écrit
  en C qui pourrait, avec un peu de chance, être inclus à PHP.
  Non seulement nous avons rencontré des problèmes techniques complexes,
  mais nous avons participés à de nombreux débats sur ce que devait
  et ce que ne devait pas faire un moteur de template. De cette expérience nous avons
  décidé qu'un moteur de template se devait d'être écrit sous la forme d'une
  classe PHP, afin que quiconque puisse l'utiliser à sa convenance. Nous
  avons donc réalisé un moteur de template qui se contentait de faire cela,
  et <productname>SmartTemplate</productname> a vu le jour (note : cette
  classe n'a jamais été soumise au public). C'était une classe qui
  faisait pratiquement tout ce que nous voulions : substitution de variables,
  inclusion d'autres templates, intégration avec des fichiers de configuration,
  intégration de code PHP, instruction 'if' basique et une gestion plus robuste
  des blocks dynamiques imbriqués. Elle faisait tout cela avec des expressions
  rationnelles et le code se révéla, comment dire, impénétrable. De plus, elle était
  relativement lente pour les grosses applications à cause de l'analyse
  et du travail sur les expressions rationnelles qu'elle devait faire à chaque
  exécution. Le plus gros problème du point de vue du programmeur était
  tout le travail nécessaire en amont, dans le script PHP, pour configurer
  et exécuter les templates, et les blocs dynamiques. Comment rendre tout ceci
  plus simple ?
 </para>
 <para>
  Puis vint la vision de ce que devait devenir Smarty. Nous
  savons combien le code PHP peut être rapide sans le coût
  d'analyse des templates. Nous savons aussi combien fastidieux
  et décourageant peut paraître le langage  pour le designer moyen, et que
  cela peut être remplacé par une syntaxe spécifique, beaucoup
  plus simple. Et si nous combinions les deux forces ? Ainsi, Smarty
  était né...
 </para>
</preface>
<!-- 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
-->