Le problème avec cette méthode (que j'ai déjà testée ;) ) est la collusion entre des variables de même nom. Typiquement le $row peut être appelé dans un sous-(sous-)*template de toto.tpl, etc.
Mon exemple est mal choisi. Personne ne t'oblige à appeler ta variable $row à chaque retour de query. Tu peux parfaitement lui donner un nom fonctionnel ($data_user, $data_produit, etc...), surtout quand tu es dans le cas classique d'aller chercher une donnée en début de script parce que tu sais que tu en auras besoin plus ou moins partout pour la suite (qu'on aille la cherche en session php ou en sgbd, peu importe). Tu peux aussi faire un unset dessus. Et enfin, rien ne t'empêche de lui donner le même nom dans deux cas du moment que tu initialises tous les champs nécessaires au 'template'. Et pour finir, j'ajouterais que 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.
Au fait, il fallait bien entendu lire $tpl->affect($row); (j'avais oublié le paramètre) dans mon exemple simplifié.
a++ JG
Le problème avec cette méthode (que j'ai déjà testée ;) ) est la
collusion entre des variables de même nom. Typiquement le $row peut être
appelé dans un sous-(sous-)*template de toto.tpl, etc.
Mon exemple est mal choisi. Personne ne t'oblige à appeler ta variable
$row à chaque retour de query. Tu peux parfaitement lui donner un nom
fonctionnel ($data_user, $data_produit, etc...), surtout quand tu es
dans le cas classique d'aller chercher une donnée en début de script
parce que tu sais que tu en auras besoin plus ou moins partout pour la
suite (qu'on aille la cherche en session php ou en sgbd, peu importe).
Tu peux aussi faire un unset dessus. Et enfin, rien ne t'empêche de lui
donner le même nom dans deux cas du moment que tu initialises tous les
champs nécessaires au 'template'. Et pour finir, j'ajouterais que 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.
Au fait, il fallait bien entendu lire $tpl->affect($row); (j'avais
oublié le paramètre) dans mon exemple simplifié.
Le problème avec cette méthode (que j'ai déjà testée ;) ) est la collusion entre des variables de même nom. Typiquement le $row peut être appelé dans un sous-(sous-)*template de toto.tpl, etc.
Mon exemple est mal choisi. Personne ne t'oblige à appeler ta variable $row à chaque retour de query. Tu peux parfaitement lui donner un nom fonctionnel ($data_user, $data_produit, etc...), surtout quand tu es dans le cas classique d'aller chercher une donnée en début de script parce que tu sais que tu en auras besoin plus ou moins partout pour la suite (qu'on aille la cherche en session php ou en sgbd, peu importe). Tu peux aussi faire un unset dessus. Et enfin, rien ne t'empêche de lui donner le même nom dans deux cas du moment que tu initialises tous les champs nécessaires au 'template'. Et pour finir, j'ajouterais que 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.
Au fait, il fallait bien entendu lire $tpl->affect($row); (j'avais oublié le paramètre) dans mon exemple simplifié.
a++ JG
loufoque
Guillaume Bouchard a dit le 09/07/2004 17:03:
Je vais encore passer pour un extremiste pas à ma place, mais en faisant du html propre, c'est à dire du html pour structurer vos données, ce qui ne change pas lors d'un changement de presentation, le maiteneur de la charte graphique n'aurait pas à mettre les mains dans le code php, juste à modifier sa feuille de style css.
C'est ce que je croyais. J'ai essayé, et j'ai beaucoup souffert pour le code CSS ensuite. Enfin c'est peut-être parce que je suis un mauvais graphiste aussi.
Guillaume Bouchard a dit le 09/07/2004 17:03:
Je vais encore passer pour un extremiste pas à ma place, mais en faisant
du html propre, c'est à dire du html pour structurer vos données, ce qui
ne change pas lors d'un changement de presentation, le maiteneur de la
charte graphique n'aurait pas à mettre les mains dans le code php, juste
à modifier sa feuille de style css.
C'est ce que je croyais.
J'ai essayé, et j'ai beaucoup souffert pour le code CSS ensuite.
Enfin c'est peut-être parce que je suis un mauvais graphiste aussi.
Je vais encore passer pour un extremiste pas à ma place, mais en faisant du html propre, c'est à dire du html pour structurer vos données, ce qui ne change pas lors d'un changement de presentation, le maiteneur de la charte graphique n'aurait pas à mettre les mains dans le code php, juste à modifier sa feuille de style css.
C'est ce que je croyais. J'ai essayé, et j'ai beaucoup souffert pour le code CSS ensuite. Enfin c'est peut-être parce que je suis un mauvais graphiste aussi.
jerome herve
Une étude (bien qu'un peu ancienne) sur les performances des templates :/
www.phpindex.com/download/templates2.php3
Une étude (bien qu'un peu ancienne) sur les performances des templates :/
Une étude (bien qu'un peu ancienne) sur les performances des templates :/
www.phpindex.com/download/templates2.php3
Thibaut Allender
Qu'est-ce qu'ils recommandent de faire les guru PHP ? Du code spaghetti où tout est joyeusement mélangé ? Mettre du HTML dans des fonctions ? Histoire que les dév. se tapent les refontes de charte graphique.
PS : Ce n'est pas de l'ironie, j'aimerai bien une réponse.
je pensais que les CSS permettaient de separer le contenu de la mise en forme... on a du me mentir
Qu'est-ce qu'ils recommandent de faire les guru PHP ?
Du code spaghetti où tout est joyeusement mélangé ?
Mettre du HTML dans des fonctions ? Histoire que les dév. se tapent les
refontes de charte graphique.
PS : Ce n'est pas de l'ironie, j'aimerai bien une réponse.
je pensais que les CSS permettaient de separer le contenu de la mise en
forme... on a du me mentir
Qu'est-ce qu'ils recommandent de faire les guru PHP ? Du code spaghetti où tout est joyeusement mélangé ? Mettre du HTML dans des fonctions ? Histoire que les dév. se tapent les refontes de charte graphique.
PS : Ce n'est pas de l'ironie, j'aimerai bien une réponse.
je pensais que les CSS permettaient de separer le contenu de la mise en forme... on a du me mentir
Donc exemple à l'appuit : les moteurs de templates ne servent pas à grand chose pour séparer la logique de la présentation avec le langage php car il est lui même déjà un moteur de templates. Même plus puissant
je pense en effet que pas mal de monde oublie un peu vite que PHP veut dire PHP *HyperText* Processor...
Donc exemple à l'appuit : les moteurs de templates ne servent pas à
grand chose pour séparer la logique de la présentation avec le langage
php car il est lui même déjà un moteur de templates. Même plus puissant
je pense en effet que pas mal de monde oublie un peu vite que PHP veut
dire PHP *HyperText* Processor...
Donc exemple à l'appuit : les moteurs de templates ne servent pas à grand chose pour séparer la logique de la présentation avec le langage php car il est lui même déjà un moteur de templates. Même plus puissant
je pense en effet que pas mal de monde oublie un peu vite que PHP veut dire PHP *HyperText* Processor...
je pensais que les CSS permettaient de separer le contenu de la mise en forme... on a du me mentir
Il faut séparer logique/pêche aux données de l'affichage. Ca on sait faire. Ensuire, la légende veut que le contenu soit séparable de sa mise en forme. En effet, si on te demande de passer tous les liens en violet gras italique et que tu as utilisé des css, tu n'as qu'à changer le code à un seul endroit. D'aileurs, si tu as écris une fonction generate_link() et que tu l'appelles systématiquement, tu n'auras qu'un seul endroit où modifier le code aussi.
Où se trouve la limite des css et autres, c'est que quand le client (le gars qui paye le site) décide de faire une mise à jour, c'est toujours quasiment toute la mise en page qui pête. Quand toto décide que le menu actuellement en haut à gauche sur la page 1 passe au milieu à droite sur la page 3, tu peux avoir css-é tout ce que tu veux, il faut refaire tous les gabarits parce que toute la mise en page est foutue. Enfin c'est ce que m'en disent les graphistes que je connais, moi je ne m'occupe pas de ces choses là.
a++ JG
je pensais que les CSS permettaient de separer le contenu de la mise en
forme... on a du me mentir
Il faut séparer logique/pêche aux données de l'affichage. Ca on sait faire.
Ensuire, la légende veut que le contenu soit séparable de sa mise en forme.
En effet, si on te demande de passer tous les liens en violet gras italique
et que tu as utilisé des css, tu n'as qu'à changer le code à un seul
endroit. D'aileurs, si tu as écris une fonction generate_link() et que tu
l'appelles systématiquement, tu n'auras qu'un seul endroit où modifier le
code aussi.
Où se trouve la limite des css et autres, c'est que quand le client (le gars
qui paye le site) décide de faire une mise à jour, c'est toujours quasiment
toute la mise en page qui pête. Quand toto décide que le menu actuellement
en haut à gauche sur la page 1 passe au milieu à droite sur la page 3, tu
peux avoir css-é tout ce que tu veux, il faut refaire tous les gabarits
parce que toute la mise en page est foutue. Enfin c'est ce que m'en disent
les graphistes que je connais, moi je ne m'occupe pas de ces choses là.
je pensais que les CSS permettaient de separer le contenu de la mise en forme... on a du me mentir
Il faut séparer logique/pêche aux données de l'affichage. Ca on sait faire. Ensuire, la légende veut que le contenu soit séparable de sa mise en forme. En effet, si on te demande de passer tous les liens en violet gras italique et que tu as utilisé des css, tu n'as qu'à changer le code à un seul endroit. D'aileurs, si tu as écris une fonction generate_link() et que tu l'appelles systématiquement, tu n'auras qu'un seul endroit où modifier le code aussi.
Où se trouve la limite des css et autres, c'est que quand le client (le gars qui paye le site) décide de faire une mise à jour, c'est toujours quasiment toute la mise en page qui pête. Quand toto décide que le menu actuellement en haut à gauche sur la page 1 passe au milieu à droite sur la page 3, tu peux avoir css-é tout ce que tu veux, il faut refaire tous les gabarits parce que toute la mise en page est foutue. Enfin c'est ce que m'en disent les graphistes que je connais, moi je ne m'occupe pas de ces choses là.
a++ JG
Zouplaz
jerome herve - :
Savut wrote:
D'habitude les vrai guru du PHP n'utilisent pas de template ou fabriquent eux-meme leur propre script de template. Comme tu ne comprend pas ton script, j'imagine tu ne l'a pas fait toi meme, il faudrait donc nous dire c quoi le programme ou le script que t'a telecharge.
les vrai guru de PHP *n'utilisent pas* les templates. Ils recommandent même de ne pas le faire. Les templates sont une abération technique qui charge les serveurs inutilement . Rappelons qu'à l'origine, PHP avait été concu pour pouvoir s'en dispenser.
Mais bon, ca fait "pro"
QQun (une brute en template php) peut il m'aider a trouver la solution a ce probleme ?
Le terme "brute" est effectivement valable.
Quitte à faire "pro" y a qu'a carrément passer à struts (je crois qu'il est porté sous php)... Déjà qu'en java on multiplie par 50 le boulot...
M'enfin, je comprends pas ces usines à gaz... J'ai essayé les jsf : rarement vu un truc aussi tordu.
Par contre, ça peut servir à impressionner les clients. Du coup, on peut facturer 3 fois plus cher un truc qui marche 3 fois moins bien ;-)
jerome herve - no@spam.no :
Savut wrote:
D'habitude les vrai guru du PHP n'utilisent pas de template ou
fabriquent eux-meme leur propre script de template. Comme tu ne
comprend pas ton script, j'imagine tu ne l'a pas fait toi meme, il
faudrait donc nous dire c quoi le programme ou le script que t'a
telecharge.
les vrai guru de PHP *n'utilisent pas* les templates. Ils recommandent
même de ne pas le faire.
Les templates sont une abération technique qui charge les serveurs
inutilement . Rappelons qu'à l'origine, PHP avait été concu pour pouvoir
s'en dispenser.
Mais bon, ca fait "pro"
QQun (une brute en template php) peut il m'aider a trouver la solution
a ce probleme ?
Le terme "brute" est effectivement valable.
Quitte à faire "pro" y a qu'a carrément passer à struts (je crois qu'il est
porté sous php)... Déjà qu'en java on multiplie par 50 le boulot...
M'enfin, je comprends pas ces usines à gaz... J'ai essayé les jsf :
rarement vu un truc aussi tordu.
Par contre, ça peut servir à impressionner les clients. Du coup, on peut
facturer 3 fois plus cher un truc qui marche 3 fois moins bien ;-)
D'habitude les vrai guru du PHP n'utilisent pas de template ou fabriquent eux-meme leur propre script de template. Comme tu ne comprend pas ton script, j'imagine tu ne l'a pas fait toi meme, il faudrait donc nous dire c quoi le programme ou le script que t'a telecharge.
les vrai guru de PHP *n'utilisent pas* les templates. Ils recommandent même de ne pas le faire. Les templates sont une abération technique qui charge les serveurs inutilement . Rappelons qu'à l'origine, PHP avait été concu pour pouvoir s'en dispenser.
Mais bon, ca fait "pro"
QQun (une brute en template php) peut il m'aider a trouver la solution a ce probleme ?
Le terme "brute" est effectivement valable.
Quitte à faire "pro" y a qu'a carrément passer à struts (je crois qu'il est porté sous php)... Déjà qu'en java on multiplie par 50 le boulot...
M'enfin, je comprends pas ces usines à gaz... J'ai essayé les jsf : rarement vu un truc aussi tordu.
Par contre, ça peut servir à impressionner les clients. Du coup, on peut facturer 3 fois plus cher un truc qui marche 3 fois moins bien ;-)
Sebastien
Je ne sais pas si j'ai été clair. Qd je parle de templates, il n'est pas question de :
... qui àmha ne servent pas à grand-chose, mais de :
<h1><?php echo $titre ?></h1>
John Gallet wrote:
Mon exemple est mal choisi. Personne ne t'oblige à appeler ta variable $row à chaque retour de query. Tu peux parfaitement lui donner un nom fonctionnel ($data_user, $data_produit, etc...)
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. Un cas ultra-classique :
Pour qu'il fonctionne il fautdrait que je vérifie que $i et $j ne sont pas utilisés dans : - les templates pères et leurs fils - le template un_template.tpl.php et ses fils C'est ingérable et donne beaucoup de boulot (dont on pourrait facilement s'abstreindre) pour pas grand-chose. Que proposer pour garantir l'unicité des noms de variables ? Les préfixer avec le nom du template courant ? Est-ce bien raisonnable ? => Il suffirait de créer un espace de données propre à chaque template :
rien ne t'empêche de lui donner le même nom dans deux cas du moment que tu initialises tous les champs nécessaires au 'template'.
Je ne vois pas ce que tu veux dire.
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 ne sais pas si j'ai été clair.
Qd je parle de templates, il n'est pas question de :
... qui àmha ne servent pas à grand-chose, mais de :
<h1><?php echo $titre ?></h1>
John Gallet wrote:
Mon exemple est mal choisi. Personne ne t'oblige à appeler ta variable
$row à chaque retour de query. Tu peux parfaitement lui donner un nom
fonctionnel ($data_user, $data_produit, etc...)
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.
Un cas ultra-classique :
Pour qu'il fonctionne il fautdrait que je vérifie que $i et $j ne sont
pas utilisés dans :
- les templates pères et leurs fils
- le template un_template.tpl.php et ses fils
C'est ingérable et donne beaucoup de boulot (dont on pourrait facilement
s'abstreindre) pour pas grand-chose.
Que proposer pour garantir l'unicité des noms de variables ? Les
préfixer avec le nom du template courant ? Est-ce bien raisonnable ?
=> Il suffirait de créer un espace de données propre à chaque template :
rien ne t'empêche de lui
donner le même nom dans deux cas du moment que tu initialises tous les
champs nécessaires au 'template'.
Je ne vois pas ce que tu veux dire.
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.
... qui àmha ne servent pas à grand-chose, mais de :
<h1><?php echo $titre ?></h1>
John Gallet wrote:
Mon exemple est mal choisi. Personne ne t'oblige à appeler ta variable $row à chaque retour de query. Tu peux parfaitement lui donner un nom fonctionnel ($data_user, $data_produit, etc...)
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. Un cas ultra-classique :
Pour qu'il fonctionne il fautdrait que je vérifie que $i et $j ne sont pas utilisés dans : - les templates pères et leurs fils - le template un_template.tpl.php et ses fils C'est ingérable et donne beaucoup de boulot (dont on pourrait facilement s'abstreindre) pour pas grand-chose. Que proposer pour garantir l'unicité des noms de variables ? Les préfixer avec le nom du template courant ? Est-ce bien raisonnable ? => Il suffirait de créer un espace de données propre à chaque template :
rien ne t'empêche de lui donner le même nom dans deux cas du moment que tu initialises tous les champs nécessaires au 'template'.
Je ne vois pas ce que tu veux dire.
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.
Sebastien
Je n'ai aucun, mais alors aucun bout de html qui traine en dehors de mon repertoire de "template", sauf que se ne sont pas des templates, mais des fichiers contenant du html et des echo $truc.
Je considère qu'un template est une page ne contenant que la logique d'affichage (pas d'accès aux données, traitements, etc.), après la manière dont tu t'y prends pour afficher les données... c'est une autre histoire ;)
Je vais encore passer pour un extremiste pas à ma place, mais en faisant du html propre, c'est à dire du html pour structurer vos données, ce qui ne change pas lors d'un changement de presentation, le maiteneur de la charte graphique n'aurait pas à mettre les mains dans le code php, juste à modifier sa feuille de style css.
Pour moi un bon dev c'est 4 trucs:
1) Le code php dans un coin 2) les "templates" PHP (et non pas un truc degeu qui n'apporte rien) dans un autre coin 3) tout ce qui est texte dans un autre coin (gettext...) 4) tout ce qui est presentation dans le dernier coin (css + images...)
On est d'accord :)
---> http://csszengarden.com/
Bel exemple de site-vitrine. Je suis curieux de voir l'équivalent avec un contenu réellement *dynamique*.
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. HTML a été désigné pour http://www.info.univ-angers.fr/pub/pn/poly/ On en a fait http://www.amazon.fr/ Y'a pas comme un malentendu ? Il serait grand temps de remettre les choses à plat. L'éditeur qui fera le premier pas (MS ?) prendra un avantage certain.
PS : Ce n'est pas de l'ironie, j'aimerai bien une réponse.
Je ne sais pas si celle-ci te convient, mais bon.
Tous les avis sont bons à prendre. Bye.
Je n'ai aucun, mais alors aucun bout de html qui traine en dehors de mon
repertoire de "template", sauf que se ne sont pas des templates, mais
des fichiers contenant du html et des echo $truc.
Je considère qu'un template est une page ne contenant que la logique
d'affichage (pas d'accès aux données, traitements, etc.), après la
manière dont tu t'y prends pour afficher les données... c'est une autre
histoire ;)
Je vais encore passer pour un extremiste pas à ma place, mais en faisant
du html propre, c'est à dire du html pour structurer vos données, ce qui
ne change pas lors d'un changement de presentation, le maiteneur de la
charte graphique n'aurait pas à mettre les mains dans le code php, juste
à modifier sa feuille de style css.
Pour moi un bon dev c'est 4 trucs:
1) Le code php dans un coin
2) les "templates" PHP (et non pas un truc degeu qui n'apporte rien)
dans un autre coin
3) tout ce qui est texte dans un autre coin (gettext...)
4) tout ce qui est presentation dans le dernier coin (css + images...)
On est d'accord :)
---> http://csszengarden.com/
Bel exemple de site-vitrine. Je suis curieux de voir l'équivalent avec
un contenu réellement *dynamique*.
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.
HTML a été désigné pour http://www.info.univ-angers.fr/pub/pn/poly/
On en a fait http://www.amazon.fr/
Y'a pas comme un malentendu ?
Il serait grand temps de remettre les choses à plat. L'éditeur qui fera
le premier pas (MS ?) prendra un avantage certain.
PS : Ce n'est pas de l'ironie, j'aimerai bien une réponse.
Je n'ai aucun, mais alors aucun bout de html qui traine en dehors de mon repertoire de "template", sauf que se ne sont pas des templates, mais des fichiers contenant du html et des echo $truc.
Je considère qu'un template est une page ne contenant que la logique d'affichage (pas d'accès aux données, traitements, etc.), après la manière dont tu t'y prends pour afficher les données... c'est une autre histoire ;)
Je vais encore passer pour un extremiste pas à ma place, mais en faisant du html propre, c'est à dire du html pour structurer vos données, ce qui ne change pas lors d'un changement de presentation, le maiteneur de la charte graphique n'aurait pas à mettre les mains dans le code php, juste à modifier sa feuille de style css.
Pour moi un bon dev c'est 4 trucs:
1) Le code php dans un coin 2) les "templates" PHP (et non pas un truc degeu qui n'apporte rien) dans un autre coin 3) tout ce qui est texte dans un autre coin (gettext...) 4) tout ce qui est presentation dans le dernier coin (css + images...)
On est d'accord :)
---> http://csszengarden.com/
Bel exemple de site-vitrine. Je suis curieux de voir l'équivalent avec un contenu réellement *dynamique*.
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. HTML a été désigné pour http://www.info.univ-angers.fr/pub/pn/poly/ On en a fait http://www.amazon.fr/ Y'a pas comme un malentendu ? Il serait grand temps de remettre les choses à plat. L'éditeur qui fera le premier pas (MS ?) prendra un avantage certain.
PS : Ce n'est pas de l'ironie, j'aimerai bien une réponse.
Je ne sais pas si celle-ci te convient, mais bon.
Tous les avis sont bons à prendre. Bye.
Guillaume Bouchard
John Gallet wrote:
Où se trouve la limite des css et autres, c'est que quand le client (le gars qui paye le site) décide de faire une mise à jour, c'est toujours quasiment toute la mise en page qui pête. Quand toto décide que le menu actuellement en haut à gauche sur la page 1 passe au milieu à droite sur la page 3, tu peux avoir css-é tout ce que tu veux, il faut refaire tous les gabarits parce que toute la mise en page est foutue. Enfin c'est ce que m'en disent les graphistes que je connais, moi je ne m'occupe pas de ces choses là.
Regarde l'exemple de csszengarden http://csszengarden.com/. Si ton client demande une petit restructuration de la mise en page, ne me dis pas que elle sera plus élaborer que celle que propose csszen... (sans changer le code html)
Dans le cas où le client fait faire un changement de contenu important comme l'ajout d'un nouveau menu par exemple. Il suffit de positioner la class qui va bien et la feuille prend le relai. Dans le cas de l'ajout d'un nouvel element (exemple d'une boite de texte dans le coin), 3-4 lignes dans la CSS et c'est bon. Ce sera de toute manière toujours plus rapide que de reprendre la complexe mise en page à base de tableaux, de rowspan et de pixels invisibles. Dans le cas d'une refonte totale du site, ce sera le même travail de refaire les complexes tableau qu'une CSS (quoi que je pense plus vite une mise en page en matiere de CSS que de tableau, l'habitude ;o))
Après, il y a telement d'autres aventages (bonne integrité visuelle, code html leger et propre, feuilles adaptées à chaques contextes (impression par exemple, evite de faire une moulinette interne pour faire des pages optimisée pour l'impression...).
J'ai, on a (le milieu des extremistes des recomandations du W3C dont je fait parti) remarquer que peut de personne dans le milieu du graphisme ne conaissent correctement les possibilitées des CSS. Ce n'est pas une critique ou un reproche, mais juste une constatation. Il suffit que ces personnes ai été formées cette année par un prof qui sortait d'ecole l'année derniere pour qu'il ne soit pas au courant, vu que je ne crois pas que cela soit beaucoup enseigner. Pour avoir passer un test dans une ecole de graphisme adapaté au web plutôt connue, je considere que les profs n'ont souvent plus le niveau.
L'informatique et le web etant ce qu'ils sont, il est imperatif de se remettre à niveau plus que dans toute autre discipline.
Après, je dit cela du haut de mes 18 ans, avec ma formation autodidacte qui n'a jamais connu le contexte professionel et ses contraintes, donc je pense que j'ai une vision un peut idealisée des choses, mais bon :)
Je fais un fu2 et X-post sur fr.comp.infosystemes.www.auteurs parce que encore une foix cela sort du cadre de ce NG.
-- Guillaume.
John Gallet wrote:
Où se trouve la limite des css et autres, c'est que quand le client (le gars
qui paye le site) décide de faire une mise à jour, c'est toujours quasiment
toute la mise en page qui pête. Quand toto décide que le menu actuellement
en haut à gauche sur la page 1 passe au milieu à droite sur la page 3, tu
peux avoir css-é tout ce que tu veux, il faut refaire tous les gabarits
parce que toute la mise en page est foutue. Enfin c'est ce que m'en disent
les graphistes que je connais, moi je ne m'occupe pas de ces choses là.
Regarde l'exemple de csszengarden http://csszengarden.com/. Si ton
client demande une petit restructuration de la mise en page, ne me dis
pas que elle sera plus élaborer que celle que propose csszen... (sans
changer le code html)
Dans le cas où le client fait faire un changement de contenu important
comme l'ajout d'un nouveau menu par exemple. Il suffit de positioner la
class qui va bien et la feuille prend le relai. Dans le cas de l'ajout
d'un nouvel element (exemple d'une boite de texte dans le coin), 3-4
lignes dans la CSS et c'est bon. Ce sera de toute manière toujours plus
rapide que de reprendre la complexe mise en page à base de tableaux, de
rowspan et de pixels invisibles. Dans le cas d'une refonte totale du
site, ce sera le même travail de refaire les complexes tableau qu'une
CSS (quoi que je pense plus vite une mise en page en matiere de CSS que
de tableau, l'habitude ;o))
Après, il y a telement d'autres aventages (bonne integrité visuelle,
code html leger et propre, feuilles adaptées à chaques contextes
(impression par exemple, evite de faire une moulinette interne pour
faire des pages optimisée pour l'impression...).
J'ai, on a (le milieu des extremistes des recomandations du W3C dont je
fait parti) remarquer que peut de personne dans le milieu du graphisme
ne conaissent correctement les possibilitées des CSS.
Ce n'est pas une critique ou un reproche, mais juste une constatation.
Il suffit que ces personnes ai été formées cette année par un prof qui
sortait d'ecole l'année derniere pour qu'il ne soit pas au courant, vu
que je ne crois pas que cela soit beaucoup enseigner. Pour avoir passer
un test dans une ecole de graphisme adapaté au web plutôt connue, je
considere que les profs n'ont souvent plus le niveau.
L'informatique et le web etant ce qu'ils sont, il est imperatif de se
remettre à niveau plus que dans toute autre discipline.
Après, je dit cela du haut de mes 18 ans, avec ma formation autodidacte
qui n'a jamais connu le contexte professionel et ses contraintes, donc
je pense que j'ai une vision un peut idealisée des choses, mais bon :)
Je fais un fu2 et X-post sur fr.comp.infosystemes.www.auteurs parce que
encore une foix cela sort du cadre de ce NG.
Où se trouve la limite des css et autres, c'est que quand le client (le gars qui paye le site) décide de faire une mise à jour, c'est toujours quasiment toute la mise en page qui pête. Quand toto décide que le menu actuellement en haut à gauche sur la page 1 passe au milieu à droite sur la page 3, tu peux avoir css-é tout ce que tu veux, il faut refaire tous les gabarits parce que toute la mise en page est foutue. Enfin c'est ce que m'en disent les graphistes que je connais, moi je ne m'occupe pas de ces choses là.
Regarde l'exemple de csszengarden http://csszengarden.com/. Si ton client demande une petit restructuration de la mise en page, ne me dis pas que elle sera plus élaborer que celle que propose csszen... (sans changer le code html)
Dans le cas où le client fait faire un changement de contenu important comme l'ajout d'un nouveau menu par exemple. Il suffit de positioner la class qui va bien et la feuille prend le relai. Dans le cas de l'ajout d'un nouvel element (exemple d'une boite de texte dans le coin), 3-4 lignes dans la CSS et c'est bon. Ce sera de toute manière toujours plus rapide que de reprendre la complexe mise en page à base de tableaux, de rowspan et de pixels invisibles. Dans le cas d'une refonte totale du site, ce sera le même travail de refaire les complexes tableau qu'une CSS (quoi que je pense plus vite une mise en page en matiere de CSS que de tableau, l'habitude ;o))
Après, il y a telement d'autres aventages (bonne integrité visuelle, code html leger et propre, feuilles adaptées à chaques contextes (impression par exemple, evite de faire une moulinette interne pour faire des pages optimisée pour l'impression...).
J'ai, on a (le milieu des extremistes des recomandations du W3C dont je fait parti) remarquer que peut de personne dans le milieu du graphisme ne conaissent correctement les possibilitées des CSS. Ce n'est pas une critique ou un reproche, mais juste une constatation. Il suffit que ces personnes ai été formées cette année par un prof qui sortait d'ecole l'année derniere pour qu'il ne soit pas au courant, vu que je ne crois pas que cela soit beaucoup enseigner. Pour avoir passer un test dans une ecole de graphisme adapaté au web plutôt connue, je considere que les profs n'ont souvent plus le niveau.
L'informatique et le web etant ce qu'ils sont, il est imperatif de se remettre à niveau plus que dans toute autre discipline.
Après, je dit cela du haut de mes 18 ans, avec ma formation autodidacte qui n'a jamais connu le contexte professionel et ses contraintes, donc je pense que j'ai une vision un peut idealisée des choses, mais bon :)
Je fais un fu2 et X-post sur fr.comp.infosystemes.www.auteurs parce que encore une foix cela sort du cadre de ce NG.
