Aide sur les Templates en PHP

Sebastien wrote:

---> http://csszengarden.com/

Bel exemple de site-vitrine. Je suis curieux de voir l'équivalent avec
un contenu réellement *dynamique*.

http://www.eyrolles.com/

Un site qui n'est pas vraiment *un petit* et qui adopte un design
integralement en CSS. Il n'y a malheureusement pas de feuille de styles
alternative pour tester ces possibilitées. Mais cela prouve que ce n'est
pas une technologie reservée au geeks extremistes.

http://guillaume.apinc.org/

Mon mien, avec deux feuilles de styles (qui ne doivent pas être super
sous IE, j'ai pas cherché à regler les problemes, c'est donc ma faute,
pas celle des CSS). Bon, la qualité de design n'est pas extra, je ne
suis pas doué dans cette discipline, mais c'est un exemple d'un site
*dynamique* :) (et j'en profite pour recuperer 3 visite de plus pour
depasser la dizaine par an :)

Le code html ne change pas, juste la feuille de style, le premier qui
me dit que c'est limité, j'attend des arguments betons avec ;o)

Dans le principe non. Mais on ne peut pas dire que (X)HTML/CSS (et son
maâagnifique modèle de boîte) est le couple idéal.

Ideal, non, mais meilleur que les tag-soupe à base de font et de table.

HTML a été désigné pour http://www.info.univ-angers.fr/pub/pn/poly/

Il y a telement d'infos que j'ai pas trouvé celle que tu voulais me
faire voir.

On en a fait http://www.amazon.fr/
Y'a pas comme un malentendu ?

Pour moi html a été crée dans le but de partager des documents. Donc un
document html bien structuré avec une presentation CSS propre par dessus
pour le coté "user-friendly" c'est bon.

Je ne pense pas que l'on soit sur le bon newsgroup pour discuter de ça.

X-Post et fu2 fr.comp.infosystemes.www.auteurs

--
Guillaume.

Sebastien a dit le 10/07/2004 17:43:

Dans le principe non. Mais on ne peut pas dire que (X)HTML/CSS (et son
maâagnifique modèle de boîte) est le couple idéal.
C'est pourtant ce que le W3C, qui est l'autorité dans le domaine, dit.

Toute logique de présentation doit se faire via CSS, l'HTML ne sert qu'à
structurer le contenu.

HTML a été désigné pour http://www.info.univ-angers.fr/pub/pn/poly/
C'est vrai que les cours d'université, ça fait office de norme

internationale.
Surtout quand ça se base sur des recommandations obsolètes (HTML3.2).

Bonjour,

On est bien d'accord, mais je ne comprends pas comment tu peux
cautionner une méthode qui entraînera *forcément*, à un moment ou à un
autre, des pertes de valeurs.

N'exagérons rien. La notion de domaine est facilement adaptable à ce cas
précis.

Un cas ultra-classique :

<?php for ( $i = 0 ; $i < $j ; $i++ ) : ?>
<?php include 'un_template.tpl.php' ?>
<?php endfor ?>


Pour qu'il fonctionne il fautdrait que je vérifie que $i et $j ne sont
pas utilisés dans :

C'est quand même pas compliqué de nommer tes variables purement locales
en les préfixant du nom de leur domaine de validité, à savoir le nom du
template où elles sont valides. Ton $i devient alors ici $tpl1_i et ton
$j devient $un_template.tpl_j ce qui interdit tout "touillage".

C'est ingérable et donne beaucoup de boulot
Nommer ses variables différement ça demande du boulot ?

préfixer avec le nom du template courant ? Est-ce bien raisonnable ?
Vu le nombre de cas à gérer, oui. Et de toutes façons la présentation

est toujours une bidouille, on fait pas propre, on fait au moins sale.

Enfin si tu veux éviter le problème, tu peux ausi encapsuler dans des
fonctions. Ca sera un peu plus pénible syntaxiquement à gérer mais c'est
tout.

=> Il suffirait de créer un espace de données propre à chaque template :
Oui tout simplement (je n'avais pas encore lu cette remarque).

<?php for ( $i = 0 ; $i < $j ; $i++ ) : ?>
<?php Template::monInclude('un_template.tpl.php') ?>
<?php endfor ?>

Gnein ? Juste le nom de la variable me parait suffisant.

je rechigne à faire des include à l'intérieur de ce type de templates, même
si rien ne l'empêche, c'est juste que ça me chiffone, il n'y a pas
vraiment de raisons pour défendre cette restriction que je m'impose en
général.

Dans ce cas les problèmes de conflit sont effectivement plus simples à
déjouer, mais c'est vraiment dommage de s'imposer une telle restriction.

Je n'en ai jamais eu le besoin pour le moment, mais je découpe beaucoup
(un peu trop ?) en fonctions indépendantes les unes des autres.

a++
JG

John Gallet a dit le 12/07/2004 12:24:

C'est quand même pas compliqué de nommer tes variables purement locales
en les préfixant du nom de leur domaine de validité, à savoir le nom du
template où elles sont valides. Ton $i devient alors ici $tpl1_i et ton
$j devient $un_template.tpl_j ce qui interdit tout "touillage".

Péfixer et tout ça c'est embêtant.

Moi je fais comme ça :
$template = new Template('/path/to/template');
$template->setVar('mavariable', $var);
$template->parse();

Et dans le template, j'utilise tout simplement $mavariable...
Voici le code de Template vite fait.

class Template {
var $file;
var $env;
function Template($file) {
$this->file = $file;
$this->env = array();
}
function setVar($name, $value) {
$this->env[] = $value;
}
function parse() {
extract($this->env);
include($this->file);
}
}

C'est tout simple, et avec ça on a aucun problème de "domaine" des
variables.

loufoque wrote:

Re,

C'est tout simple, et avec ça on a aucun problème de "domaine" des
variables.

Non en effet, mais on a souvent des problèmes de cache interne du
parseur de templates dès qu'on veut gérer des hiérarchies de templates
imbriqués. De toutes façons, là je réitère, c'est mon avis et je le
partage, oui on peut facilement séparer la logique et la présentation,
et donc faire propre dans la partie codage réel, mais la partie
présentation reste toujours de la bidouille.

a++
JG