Comment organiser ses fichiers ? [FAQ]

[paterson]

Bonjour , je souhaiterai savoir comment il faut organiser ses fichier , pour pouvoir facilement développer plus tard

je pense :

index.php

Code :

1
2
3
4
5
6
7
8
9
10
11
12
 
<?php
include("./fonctions.php");//toutes les fonctions que j'utilise souvent que j'ai créé 
switch($_GET['m'])
{
case 1:
include("./....php");
break;
...
}
....
?>

ensuite il auras tout les script de gession dans le dossier ./

et tout se que l'on voit dans le dossier ./texte/

pour permettre de modifier facilement ,

Qu'en dites vous / comment faites vous ?

Merci d'avance

[ratapapa]

Je dirais que ca dépend de la taille de l'application/du site, et de ce qu'on attend d'elle/de lui.

Il faut trouver la bonne hiérarchie qui permettra :
- de ne pas avoir un répertoire par fichier php.
- de ne pas avoir un répertoire contenant 100 fichiers php.
- de se retrouver intuitivement si quelqu'un reprend le travail.

Il n'y a pas de règle bien défini.
Personnellement les répertoires qui se retrouvent (quasiment) tout le temps : un rep "config" ou je loge mes fichiers de fonctions, constantes, connexion ; un rep "design" ou on logera css, images, etc ; souvent un rep "template" qui contient les vues.

[Raideman]

Moi je fonctionne par thème avec comme l'a dit ratapapa un souci de ne pas avoir de dossiers trop remplis ou des dossiers vides.
Généralement j'ai:
un rep config ou j'entrepose mes fichiers de configuration (général du site, mysql).
un rep classes ou je mets mes classes php.
un rep images ou je mes les images
un rep graphics avec mes fonctions d'affichage
un rep lib ou je mets les librairies que j'utilise

voila pour te donner une idée.

J'évite les sous-dossiers sur les pages visibles par tout le monde de mon site en fait.

[paterson]

Merci , sinon , dans ton docier librairies , s'est pas les librairies en C ? ou il en a aussi en C ?

Sinon est ce que je fait bien :

J'ai un fichier include.php , ou j'ai créé toutes les fonctions que j'ai créé et que j'utilise souvant (Les fonction en javascript , mise en forme mail , BBcode ..... )

pour l'instant il en a pas tellement ( 5 ) est se que set technique est interessante , ou s'est nul ?

[Raideman]

perso j'ai un include "functions.php" ou je mets mes fonctions pratiques que j'utilise partout (j'en avais meme fait une classe a part entiere pour etre en accord avec le reste du code).
Je pense que l'idée de faire un fichier functions est bonne si on ne prend pas l'habitude de le remplir de fonctions qui n'ont rien à y faire normalement lol
Bref, le tout c'est d'avoir quelque chose de compréhensible et de structuré autant que faire se peut.

[haltabush]

Pour ma part, en plus des classiques config, image, et styles, j'utilise 2 répertoires importants.
L'un, "ssi" (server side include), est composé d'éléments de ma page, par exemple le pied de page, le menu, ...
Un autre, "includes", contient du code PHP qui ne s'occupe pas des affichages, par exemple mes classes, mes traductions (enfin pour ça tout dépend de votre système de trad), ...
J'ai aussi un dossier Ajax (parfois appelé server side request, ssr) où je stocke mes requêtes serveurs Ajax.

[Yogui]

Salut

Le plus efficace est d'avoir ces éléments :

• /web/offline/ : Répertoire situé hors de la racine DocumentRoot d'Apache, donc inaccessible par un navigateur Web ;
• /web/offline/shared/ : Les biblios utilisées par tous tes sites ;
• /web/offline/sites/ : Les classes, fonctions et autres inclusions classées par site ;
• /web/online/ : Les sites, accessibles par un navigateur Web.

Pour un serveur hébergeant une galerie d'images et un forum, cela peut donner :

• /web/offline/shared/
• /web/offline/shared/fpdf/
• /web/offline/shared/jpgraph/
• /web/offline/shared/smarty/
• ...
  
• /web/offline/sites/
• /web/offline/sites/gallery/
• /web/offline/sites/gallery/config.php
• /web/offline/sites/gallery/functions.php
• /web/offline/sites/gallery/classes/
• /web/offline/sites/gallery/exceptions/
• /web/offline/sites/gallery/templates/
• /web/offline/sites/gallery/templates/default/
• /web/offline/sites/gallery/templates/default/cache/
• /web/offline/sites/gallery/templates/default/compiled/
• /web/offline/sites/gallery/templates/default/configuration/
• /web/offline/sites/gallery/templates/default/html/
• ...
  
• /web/offline/sites/forum/
• /web/offline/sites/forum/config.php
• /web/offline/sites/forum/functions.php
• /web/offline/sites/forum/classes/
• /web/offline/sites/forum/exceptions/
• /web/offline/sites/forum/templates/
• /web/offline/sites/forum/templates/default/
• /web/offline/sites/forum/templates/default/cache/
• /web/offline/sites/forum/templates/default/compiled/
• /web/offline/sites/forum/templates/default/configuration/
• /web/offline/sites/forum/templates/default/html/
• ...
  
• /web/online/gallery/index.php
• /web/online/gallery/image.php
• /web/online/gallery/admin/index.php
• /web/online/gallery/css/
• /web/online/gallery/images/
• /web/online/gallery/js/
• ...
  
• /web/online/forum/index.php
• /web/online/forum/forum.php
• /web/online/forum/thread.php
• /web/online/forum/post.php
• /web/online/forum/admin/index.php
• /web/online/forum/css/
• /web/online/forum/images/
• /web/online/forum/js/
• ...
  

En orange, ce qui n'est pas situé à l'intérieur de DocumentRoot ; en vert, ce qui l'est (et donc accessible par URI classique).
Bien entendu, l'arborescence sous "shared" est à partager entre tous les sites du même serveur.

Cela vous semble-t-il correct ?

[dhallennem]

L'arborescence proposée par Yogui est très bien car elle correspond bien aux attentes générales du découpage d'une appli PHP.
Evidemment, cela dépend pour beaucoup de la taille de ton appli ; car si tu as un fichier par répertoire cela ne sert pas à grand chose, si ce n'est la séparation online/offline pour éviter l'accès par un navigateur web à ton contenu offline.

[Yogui]

Une alternative prend en charge SSL :

• offline/shared/
• offline/shared/fpdf/
• offline/shared/smarty/
• offline/sites/
• offline/sites/galerie/
• offline/sites/forum/
• online/http/
• online/http/galerie/
• online/http/forum/
• online/https/
• online/https/galerie/
• online/https/forum/

[ratapapa]

Ce genre d'architecture est toutefois orienté web, pour une application de type intranet voire extranet (en particulier avec des outils propres à l'entreprise) un découpage par module est tout de même préférable à mon avis.

[Yogui]

Je te parle de l'arborescence des dossiers dans ton système de fichiers. Pour l'architecture sur le site Web, regarde du côté des vhosts dans la configuration d'Apache.
Ou alors je ne comprends pas ce que tu entends par "module"...

Un module n'est-il pas, dans mon exemple, "galerie" ou bien "forum" ? C'est ce que j'appelle "site".

Un module (puisque le terme est générique, on peut lui faire dire ce que l'on veut) peut aussi se référer à une branche de l'arborescence : les bibliothèques, les classes personnalisées ou bien la partie à rendre visible par URI.

[ratapapa]

Un intranet typiquement possède plusieurs modules (dans la mesure ou il est assez conséquent). Cela correspond assez régulièrement aux cas d'utilisation de niveau 2 si l'on a utilisé UML pour l'analyse.
On retrouvera par exemple la gestion financière, gestion commerciale, gestion des stocks, statistiques, communication interne, etc.

Dans ce cas précis mieux vaut séparer par module, et bien distinguer la partie frontOffice du backOffice.

Ceci n'est qu'un exemple parmi d'autres, mais pour ce genre d'application la notion de site n'a pas le même sens que sur un serveur hébergeant des sites internet.

[Yogui]

Cela m'intéresse, peux-tu donner un exemple concret ?

[ratapapa]

Un exemple concret non mais je peux prendre un exemple imaginaire

Une société souhaite gérer l'ensemble de son activité via un intranet.
C'est une société industrielle fabriquant des stylos (toute ressemblance avec la réalité serait purement fortuite).
Elle désire donc gérer son stock de matières premières, ses commandes clients, sa facturation ainsi que des statistiques sur son activité et l'évolution par rapport au passé.
La partie backoffice permettra d'administrer tous les produits disponibles (stylo 4 couleur, feutre, etc), ainsi que le paramétrage des factures et des statistiques.

On aura donc une partie publique, correspondant au frontoffice, qui possèdera l'arborescence suivante :
- un répertoire stock
- un répertoire client
- un répertoire statistiques

Pour le backOffice cela dépend de la taille de l'application, si cela reste assez sommaire on peut tout rassemble dans un dossier private par exemple, mais si l'appli est assez conséquente je préfère pour ma part séparer les modules encore une fois.

Ainsi au choix : soit un répertoire public et privé dans chaque répertoire de module, soit la même arborescence que le frontOffice mais dans une partie privée.

Ensuite les fonctions et constantes mises dans un répertoire à part, et le design idem.
Dans notre société nous utilisons un framework "maison" nous avons donc notre propre arborescence pour le stocker

[Yogui]

Dans un tel cas, ne peut-on pas considérer que chaque module est en fait un site indépendant, même si tous partagent vraisemblablement la même base de données ?
Pour le backoffice, soit il constitue un module à lui seul, soit plusieurs.

Je ne parlais effectivement pas de concret au niveau du cas d'études mais des répertoires, puisque c'est l'objet initial de la discussion

[ratapapa]

Effectivement l'arborescence sera alors la même en voyant les choses ainsi, si ce n'est le design et les fonctions qui ne seront pas spécifiques à un site dans le cas d'une application intranet, mais bien souvent communes (séparées par des fichiers plus que par une arborescence)