programmation php pour site

[psychobud]

bonjour,

j'ai l'intention de faire un projet php que je veux mettre sur mon site au final. j'aimerais savoir quelle structure de projet je dois adopter. je voudrais érire mes classes avec les méthodes et puis avoir un autre fichier où j'appelle mes classes et mes méthodes (ce serait en fait la page affichée).

pourriez-vous me donner l'arborescence des fichiers ainsi que leur extension svp ... ? sont-ils tous en .php ?

bonne journée

[windu.2b]

salut,

Voici l'arborescence que j'ai tendance à utiliser (Quarky qui traîne souvent par ici utilise sensiblement la même... normal, on est dans la même classe Donc on peut te garantir que ca marche putôt bien comme arbrescence) :

/_ index.php
|_ classes/
|_ include/
|_ skin/
|_ public/
|_ private/
|_ admin/

_ La page index.php se contente de renvoyer vers public/index.php

_ Le rép 'classes' contiendra tes classes php (nommées MaClasse.class.php par ex),

_ Le rép 'include' contiendra des fichiers de fonctions que tu n'as pas pu mettre dans une classe ainsi que le fichier de configuration (codes d'accès à ta base de données, ou constantes nécessaires dans tout ton code par ex)

_ Le rép 'skin' contiendra les feuilles de style css, les squelette XHTML, les scripts JavaScript

_ Le rép 'public' contiendra les pages accessibles par tout le monde (même les visiteurs non identifiés)

_ Le rép 'private' contiendra les pages accessibles seulement aux personnes identifiées

_ Le rép 'admin' contiendra les pages de l'administration du site (il faut là aussi être identifié pour y accéder)

Cette arborescence est adaptable bien sûr: tu peux rajouter un rép 'media' pour les vidéos/photos/sons que tu veux proposer au DL le cas échéant, ou bien rajouter de nouveaux répertoires pour les statuts si les 3 public/private/admin ne te suffisent/conviennent pas

autre chose: si la page index.php à la racine renvoie vers la page public/index.php c'est pour une raison toute simple (et c'est le but de cette arborescence): avoir une arborescence "plate"!

Ca veut dire que de n'importe quel endroit, pour appeler une page ailleurs il te suffira de faire "../NomRepertoire/Nomfichier.Extension". C'est très pratique car tu n'as pas à te soucier de là où tu te trouves et donc tu n'auras pas à compter le ombre de sous-répertoires qu'il faudra prendre en compte.

Même mieux, si tu es dans public, tu peux tout à fait faire "../public/autreFichier.php"

tu remontes pour revenir dans le même répertoire, certes. Mais si ce chemin est dans une de tes classes, il sera valable quelque soit l'endroit où tu te trouves, le but étant ainsi de rendre le code dans tes classes indépendants de l'endroit où il sera appelé.

Edit: donc une page se présenterait comme suit:

//page public/index.php
<?php
/*
*appel des classes
* si tu fais du PHP5, tu peux utiliser la fonction __autoload() qui est très pratique
*/

/*
* ton code pour cette page, qui fait appel à des méthodes de tes classes par ex.
* tu remplis tes variables destinées au squelette HTML ici
*/

include("../skin/squelette.html.php");
?>

À la fin de ta page php, tu appelles ton squelette XHTML, dans lequel tu auras placé des variables php à afficher (du genre "<?php echo $titre; ?>") et ces variables auront été remplies préalablement.

Ainsi, tu peux créer le squelette de ta page indépendamment de ton code PHP, pratique si tu veux changer un détail sans avoir à tout modifier

[TheGuit]

Bon grosso modo voila pour moi :

/- index.php
|- _design
|- _inc
|- _cache
|- _admin
|- <un dossier par parti du site>

J'utilise un systeme presque semblable pour mes page PHP a la fin j'inclue mon squelette mais a la difference c'est que je ne fait pas un affichage direct. Je contatène toutes mes chaine dans une variable que j'ecrit ensuite dans un fichier texte et je fait un echo apres. Une fois dans le fichier texte j'irait juste affiché le contenu du fichier texte tant que la durée pendant la quel se cache est valide n'a pas expiré.

[Mandor]

Personnellement, j'use et j'abuse de l'URL rewriting pour "masquer" l'arborescence réelle du site et présenter de belles adresses à l'utilisateur.

Typiquement, l'achitecture de l'un de mes sites ressemble à celles présentées ci-dessus, à la différence qu'à la racine, en plus du fichier index.php, j'ai un .htaccess qui ressemble à:

RewriteEngine	On
RewriteRule	^(.+)$		index.php?$1		[QSA,L]

Toutes les requêtes seront donc redirigées sur le fichier index.php qui pourra les analyser et inclure les scripts PHP qui vont bien.

Exemple typique, si mes includes sont dans le répertoire /includes, index.php va ressembler à ça:

preg_match_all('#/([^/]+)#', $_SERVER['REQUEST_URI'], $argv);
if (isset($argv[1])) {
if (preg_match('/^[a-z]+$/', $argv[1]) && file_exists('includes/'.$argv[1].'.php')) {
	// Inclusion du module demandé.
	include('includes/'.$argv[1].'.php');
} else {
	// URL invalide ou page inexistante.
	tigger_error('La page que vous avez demandé n\'existe pas!', E_USER_ERROR);
}
} else {
// Pas d'arguments, affichage de la page d'accueil.
include('includes/accueil.php');
}

Dans cet exemple, un error handler a été définit précédement pour afficher une page d'erreur type 404 à l'appel de trigger_error. Après, il y a aussi quelques subtilités à ajouter pour les pages à accès restreint et il faut bien penser à mettre un fichier .htaccess avec "RewriteEngine Off" dans les répertoires qui devront pouvoir être liés directement (images, css, js, etc).

Ca peut paraitre inutilement compliqué, mais au final les adresses de ton site vont ressembler à: http://www.monsite.com/mapage/exemple/

En somme une suite de "répertoires virtuels", qui bien sûr n'existent pas concrêtement, mais bien plus agréable à manipuler que des http://www.monsite.com/index.php?page=mapage&var=exemple

Sans compter que d'un point de vue de sécurité, par défaut aucun fichier de l'arborescence n'est directement accessible à cause du rewriting systématique (à moins de l'avoir explicitement desactivé dans certains répertoires comme expliqué ci-dessus) et toutes les requêtes passent par index.php, ce qui permet un bien meilleur contrôle.

Quand aux inclusions, comme elles sont toutes faites à partir de la racine, ça simplifie egalement pour les chemins relatifs.

Il faut aussi savoir que les moteurs de recherche aiment beaucoup ce type de fonctionnement dans un site.

[tsubasaleguedin]

Personnellement, j'use et j'abuse de l'URL rewriting pour "masquer" l'arborescence réelle du site et présenter de belles adresses à l'utilisateur.

Typiquement, l'achitecture de l'un de mes sites ressemble à celles présentées ci-dessus, à la différence qu'à la racine, en plus du fichier index.php, j'ai un .htaccess qui ressemble à:

RewriteEngine	On
RewriteRule	^(.+)$		index.php?$1		[QSA,L]

Toutes les requêtes seront donc redirigées sur le fichier index.php qui pourra les analyser et inclure les scripts PHP qui vont bien.

Exemple typique, si mes includes sont dans le répertoire /includes, index.php va ressembler à ça:

preg_match_all('#/([^/]+)#', $_SERVER['REQUEST_URI'], $argv);
if (isset($argv[1])) {
if (preg_match('/^[a-z]+$/', $argv[1]) && file_exists('includes/'.$argv[1].'.php')) {
	// Inclusion du module demandé.
	include('includes/'.$argv[1].'.php');
} else {
	// URL invalide ou page inexistante.
	tigger_error('La page que vous avez demandé n\'existe pas!', E_USER_ERROR);
}
} else {
// Pas d'arguments, affichage de la page d'accueil.
include('includes/accueil.php');
}

Dans cet exemple, un error handler a été définit précédement pour afficher une page d'erreur type 404 à l'appel de trigger_error. Après, il y a aussi quelques subtilités à ajouter pour les pages à accès restreint et il faut bien penser à mettre un fichier .htaccess avec "RewriteEngine Off" dans les répertoires qui devront pouvoir être liés directement (images, css, js, etc).

Ca peut paraitre inutilement compliqué, mais au final les adresses de ton site vont ressembler à: http://www.monsite.com/mapage/exemple/

En somme une suite de "répertoires virtuels", qui bien sûr n'existent pas concrêtement, mais bien plus agréable à manipuler que des http://www.monsite.com/index.php?page=mapage&var=exemple

Sans compter que d'un point de vue de sécurité, par défaut aucun fichier de l'arborescence n'est directement accessible à cause du rewriting systématique (à moins de l'avoir explicitement desactivé dans certains répertoires comme expliqué ci-dessus) et toutes les requêtes passent par index.php, ce qui permet un bien meilleur contrôle.

Quand aux inclusions, comme elles sont toutes faites à partir de la racine, ça simplifie egalement pour les chemins relatifs.

Il faut aussi savoir que les moteurs de recherche aiment beaucoup ce type de fonctionnement dans un site.

Exellent merci pour les autres , ya quelques idées qui sont interressantes

[psychobud]

/_ index.php
|_ classes/
|_ include/
|_ skin/
|_ public/
|_ private/
|_ admin/

_ La page index.php se contente de renvoyer vers public/index.php

_ Le rép 'classes' contiendra tes classes php (nommées MaClasse.class.php par ex),

_ Le rép 'include' contiendra des fichiers de fonctions que tu n'as pas pu mettre dans une classe ainsi que le fichier de configuration (codes d'accès à ta base de données, ou constantes nécessaires dans tout ton code par ex)

_ Le rép 'skin' contiendra les feuilles de style css, les squelette XHTML, les scripts JavaScript

_ Le rép 'public' contiendra les pages accessibles par tout le monde (même les visiteurs non identifiés)

_ Le rép 'private' contiendra les pages accessibles seulement aux personnes identifiées

_ Le rép 'admin' contiendra les pages de l'administration du site (il faut là aussi être identifié pour y accéder)

Merci beaucoup windu.2b cela me permettra de démarrer correctement et facilement. les posts qui suivent le tien sont obsurs pour moi (mais intéressants !). par contre est-ce que le dossier _include peut être vide ?

merci encore pour toutes ces réponses

[TheGuit]

Pourquoi mettre un dossier vide ? si tu n'en voie pas l'utilité tu ne le met pas :)

[windu.2b]

Merci beaucoup windu.2b cela me permettra de démarrer correctement et facilement. les posts qui suivent le tien sont obsurs pour moi (mais intéressants !). par contre est-ce que le dossier _include peut être vide ?

merci encore pour toutes ces réponses

De rien, content de savoir que ca t'a aidé...

Et sinon, pour le dossier 'include' (je ne mets de '_' personnellement, il y était mais pour "dessiner" l'arborescence en fait ), tu n'es pas obligé de l'utiliser et/ou tu peux le laisser vide!

De-même pour les autres, tu n'es pas non plus obligé de respecter les noms des répertoires....

À toi d'adapter ton arborescence en fonction de tes besoins et de tes habitudes/règles de codage. Nous nous "contentons" de te donner nos habitudes de travail (au passage, je te recommande de bookmarker cette page, car les propositions des autres sont très intéressantes aussi, quoique pas forcément simples au premier abord), règles de codage que nous avons sans doute tous testé dans ses derniers retranchements et que nous avons adapté au fur et à mesure que nous rencontrions des cas particuliers.