includes de modules ou header+footer génériques

libuma · 29/11/2011, 18h13

Bonjour à tous,

J'aimerais votre avis sur la manière dont programmer votre site web.
Je vois deux approches :
- Tout d'abord, utiliser une page principale où seul le corps de la page change (include module.php)

- Ensuite, avoir un header.php et footer.php communs pour toutes les pages

La première approche me semble plus propre, mais on a par exemple comme inconvénient, l'URL qui restera toujours ".../index.php?mod=..." (sauf si on joue avec de l'URL Rewriting)

Et dans l'autre approche, par exemple, on a une séparation des balises ouvrantes (<html>,<head>..) et fermantes dans deux fichiers différents. Ce qui provoque des warnings qui n'ont pas lieu d'être.

Merci d'avance pour vos réactions!

Bovino · 29/11/2011, 18h44

C'est clairement la seconde approche qu'il faut privilégier !
D'autant que je vois mal de quels warnings tu veux parler...
Si c'est au niveau de ton EDI, on dira que c'est pas bien grave, mais il en existe qui gèrent très bien ce genre d'inclusions.

libuma · 29/11/2011, 19h18

Citation:

Envoyé par Bovino

C'est clairement la seconde approche qu'il faut privilégier !
D'autant que je vois mal de quels warnings tu veux parler...
Si c'est au niveau de ton EDI, on dira que c'est pas bien grave, mais il en existe qui gèrent très bien ce genre d'inclusions.

Effectivement, je parle de l'EDI. Eclipse, par exemple, me dit qu'il n'existe pas de balise de fin.
La première n'est-elle pas plus facile ?
Pour gérer un onglet actif avec une couleur différente par exemple.
On sait directement si module X => donner l'id actif à l'onglet X.

Comment procédez-vous avec la deuxième approche ?

Climoo · 06/12/2011, 21h16

Personnellement, je préfère la première méthode. Pas pour les warnings de ton IDE, mais parce que c'est plus adaptable.

Aujourd'hui tu as un header et un footer ok. Mais demain, peut être tu auras un panneau latéral. Il faudrait donc faire un nouvel include sur chacune de tes pages PHP. Un peu lourd de changer toutes tes pages PHP, dans lesquelles tu auras pris soin, chaque fois que tu en as une nouvelle, de faire un copier/coller ?
Mais bon à la limite, c'est encore faisable raisonnablement. Cela dit, je pense qu'en creusant un peu, on pourrait trouver des exemples où ce genre de méthode est pénalisant.
En général, quand on fait un copier/coller partout d'un même bout de code, c'est que l'on est passé à côté de quelque chose.

Je pense (mais ça n'engage que moi) que la méthode un seul fichier index.php (avec URL rewriting en bonus), est une bonne approche. On sait quel fichier PHP est appelé par le client, c'est toujours le même. Un avantage pour la sécurité quand même. C'est d'ailleurs en général comme ça que fonctionne plusieurs frameworks modernes orienté objet.

29/11/2011, 18h13	#1
libuma Membre actif Inscription : février 2008 Messages : 455 Détails du profil Informations forums : Inscription : février 2008 Messages : 455 Points : 161 Points : 161	includes de modules ou header+footer génériques Bonjour à tous, J'aimerais votre avis sur la manière dont programmer votre site web. Je vois deux approches : - Tout d'abord, utiliser une page principale où seul le corps de la page change (include module.php) - Ensuite, avoir un header.php et footer.php communs pour toutes les pages La première approche me semble plus propre, mais on a par exemple comme inconvénient, l'URL qui restera toujours ".../index.php?mod=..." (sauf si on joue avec de l'URL Rewriting) Et dans l'autre approche, par exemple, on a une séparation des balises ouvrantes (<html>,<head>..) et fermantes dans deux fichiers différents. Ce qui provoque des warnings qui n'ont pas lieu d'être. Merci d'avance pour vos réactions!
	00

29/11/2011, 18h44	#2
Bovino Responsable Développement Web Didier Mouronval Développeur Web Inscription : juin 2008 Messages : 13 808 Détails du profil Informations personnelles : Nom : Didier Mouronval Âge : 41 Localisation : France, Gironde (Aquitaine) Informations professionnelles : Activité : Développeur Web Secteur : High Tech - Éditeur de logiciels Informations forums : Inscription : juin 2008 Messages : 13 808 Points : 35 789 Points : 35 789	C'est clairement la seconde approche qu'il faut privilégier ! D'autant que je vois mal de quels warnings tu veux parler... Si c'est au niveau de ton EDI, on dira que c'est pas bien grave, mais il en existe qui gèrent très bien ce genre d'inclusions. __________________ Pas de question technique par MP ! Tout le monde peut participer à developpez.com, vous avez une idée, contactez-moi ! Vous possédez un blog et aimeriez diffuser vos billets sur le forum, contactez-moi ! Mes formations video2brain : La formation complète sur JavaScript • JavaScript et le DOM par la pratique • PHP 5 et MySQL : les fondamentaux Mon livre sur jQuery
	00

06/12/2011, 21h16	#4
Climoo Membre confirmé Clément Développeur informatique Inscription : décembre 2006 Messages : 213 Détails du profil Informations personnelles : Nom : Clément Localisation : France Informations professionnelles : Activité : Développeur informatique Informations forums : Inscription : décembre 2006 Messages : 213 Points : 277 Points : 277	Personnellement, je préfère la première méthode. Pas pour les warnings de ton IDE, mais parce que c'est plus adaptable. Aujourd'hui tu as un header et un footer ok. Mais demain, peut être tu auras un panneau latéral. Il faudrait donc faire un nouvel include sur chacune de tes pages PHP. Un peu lourd de changer toutes tes pages PHP, dans lesquelles tu auras pris soin, chaque fois que tu en as une nouvelle, de faire un copier/coller ? Mais bon à la limite, c'est encore faisable raisonnablement. Cela dit, je pense qu'en creusant un peu, on pourrait trouver des exemples où ce genre de méthode est pénalisant. En général, quand on fait un copier/coller partout d'un même bout de code, c'est que l'on est passé à côté de quelque chose. Je pense (mais ça n'engage que moi) que la méthode un seul fichier index.php (avec URL rewriting en bonus), est une bonne approche. On sait quel fichier PHP est appelé par le client, c'est toujours le même. Un avantage pour la sécurité quand même. C'est d'ailleurs en général comme ça que fonctionne plusieurs frameworks modernes orienté objet.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email