Vos techniques pour le développement de sites en PHP

Malgré que le sujet date un peu (2 mois), je le laisse ouvert car il est fort intéressant.

Moi mon arborescence est comme ceci :
./index.php
./libs/
./libs/functions.php
./libs/config.php
./libs/class/
./libs/ajax/
./cache/
./cache/html/
./cache/forums/
./html/
.. etc

Concernant mon système de pages, je centralise tout sur la page index.php (à la racine) et j'inclue la page demandée ($_GET['p']) si elle existe. Il y a aussi un autre paramètre en jeu : $_GET['act']. Ca permet de savoir si la page demandée est une "sous-page" ou pas. J'entends par sous-page par exemple si je demande la page "voir un forum" ou "voir un sujet", alors que l'index des forums n'est pas une sous-page (je fonctionne un peu que l'id de la page présent dans les url du SdZ).

Sinon côté class, je n'ai pas grand chose (pour le moment) à part la classe template (importante). Je réfléchis à la conception d'une classe pour le cache pour optimiser davantage mon script.

Je stocke les pages et les sous pages dans un tableau, pour vérifier si elles existent ou pas :
Code : PHP - Afficher / masquer les numéros de ligne
Et pour les noms de pages dynamiques, je combine sprintf() avec le titre de la page en question ('%s' sera alors remplacé par le titre dynamique). Enfin c'est assez compliqué à expliquer dit comme ça.

Personnellement Shepard, je vais essayer de faire mon site en POO. A vrai dire, c'est vraiment un casse tête Il se base fortement sur le modèle MVC pour Gaga971


Personnellement j'ai une classe abstraite nommée 'level' qui contient une fonction pour démarrer l'étape et une autre pour passer a l'étape suivante.

Pour la première étape, j'ai ma classe root (qui hérite bien sure de level) qui va faire son job (voir schéma) en démarant avec la fonction start_level(). A la fin de la fonction start_level(), il y aura la fonction next_level() qui se chargera de passer la main au contrôleur (voir schéma).

La seconde étape est le contrôleur approprié qui hérite de ma classe abstraite controller qui elle même hérite de la classe level.
La classe abstraite contient quelques méthodes (voir schéma) :
Code : Autre - Afficher / masquer les numéros de ligne

Ensuite, la troisième et dernière étape : le Moteur de template. Il fonctionne comme un moteur de template habituelle sauf qu'il parsera des fichiers XML et aura un contrôle directe sur le site (il ne s'agit pas qu'une suite de fonction) grâce à la fonction start_level() qui vérifiera par exemple si il n'y a pas un fichier cache XML utilisable. La fonction next_level() servira donc à envoyer les donnés au client et pourquoi pas, les cachés.


Voilà, maintenant, voici le schéma principal (non terminé, et simplifié pour une meilleur lisibilité). Je pourrais aussi mettre les UML de mes classes mais j'ai la flemme et ils ne sont pas finis (si on peut appeler ça du UML)

Pour ma part je n'utilise ni moteur de template ni POO (ou très peu).
Citation : Mon arborescence
Sinon je fais comme Aravis, une page pour chaque système (news, membre, admin, fiche, etc) ce qui me permet deséparer les fonctionnalités (et puis j'aime pas avoir trois tonnes de pages).

Racine

• admin
• forums
• img
• includes (fonctions et cfg)
• contenus (news, archives et autre fichiers relatifs aux données du site)
• designs(mes deux fichiers css et les fichiers php
• scripts (espace_membre etc...)

Très banal quoi

Moi, je n'ai pas vraiment de structure définie, elle est en cours d'élaboration permanente... Je tend à m'approcher de MVC avec séparation des requêtes SQL, comme Shepard mais en un seul fichier par module (add, del, edt dans le même fichier), ainsi qu'un système de templates.
J'utilise également un index.php avec un tableau des pages autorisées. Ceci dit je suis ouvert pour une discussion sur les architectures possibles.

Je trouve ça un peu bête que chacun énumère le système qu'il utilise : il faudrait pouvoir en tirer quelque chose. Veldryn est un des seul (le seul ?) à avoir réellement argumenter ses choix.
Mais il y a de bonnes idées chez presque tout le monde. Le coup du titre de la page dynamique pour Cam est très bon je trouve.

Bref, j'ai pas argumenté non plus moi-même sur ce coup-là, mais je promet de lire le sujet plus en détails très bientôt et de lister les trucs que je trouve bien/mal afin d'ouvrir une discussion encore plus intéressante.

PS : désolé d'être rabat-joie

Le fait de séparer toutes les requêtes sql comment procédez-vous ?

Merci

Sinon pour moi:

• index.php
• event.php
• news.php
• admin
  
  • index.php
  • css/
  • img/
  • inc/
  • module
    
    • news
      
      • index.php
      • liste_news.php
      • add_news.php
      • edt_news.php
      • del_news.php
      
      
    • user
    • event
    • photos
    
    
  
  
• css
• img
• inc

Chaque module à sa propre page, elles ne passent pas par index.php.
Le dossier "inc" contient "header" et "footer" pour la base des pages

Mais je sais pas si cette structure à long terme me conviendra, je suis à la rechere pour l'améliorer

Travaillant sur plusieurs projets à la fois, je reprend toujours les même bases car sinon c'est le bordel, et pour compatibilité.

De plus, vu que nous sommes parfois plusieurs à travailler sur un projet, nous découpons on classe pour une meilleure portabilité.

On travail tout sur un index.php central.

• index.php
• header.php
• js/
• ajax.js
• core.js
• window.js
• lib/
• lib.images.php
• lib.ftp.php
• lib.date.php
• lib.plugins.php
• class/
• class.sql.php
• class.users.php
• class.template.php
• design/
• default/
• design.css
• template.tpl
• img/
• conf/
• conf.functions.php
• conf.vars.php
• conf.defines.php
• conf.bdd.php
• img/
• cron/
• cron.inactive.php
• admin/
• index.php
• header.php
• doc/
• index.html
• inscriptions.html
• plugins/
• Calendar/
• calendar.class.php
• calendar.design.php
• calendar.conf.php
• ImportCVS/
• lang/
• fr/
• lang.main.php
• lang.news.php
• en/
• de/

Très bonne idée ce sujet, je l'avais pas encore vu ! Alors, je répond à un post un peu plus vieux.

Citation : Gaga971
Mon dernier auquel j'ai contribué est développé suivant une approche tendant à se rapprocher du modèle MVC. Personnellement, je trouve assez lourd le fait d'avoir trois fichiers par page, mais je reconnais que cela simplifie admirablement le code et rend presque inutile l'usage d'un moteur de templates, puisque la vue remplit ce rôle.
C'est donc au final un peu lourd je trouve mais pratique.

Puisque Shepard a l'air de bien connaître l'architecture de SdZ ( ), j'ai lu avec attention ses posts concernant cela, et je ne puis m'empêcher de trouver là encore un peu beaucoup un fichier par action. Je vois les avantages (séparation du code, recherche d'erreurs facilité), mais cela me parait extrême. A ce propos, dans ces fichiers, c'est sous forme de fonctions le code je suppose ?

J'ai vu qu'il allait essayer de recoder le karatemplates, vivement que tu le fasses, je suis preneur direct. Il a l'air excellent ce script !

Citation : vincent1870
Personnellement, comme je l'ai dit plus haut, je procède un peu de cette façon. En fait, à chaque page est assigné l'id de la page (idp). En fait, j'ai une page pour l'action "supprimer un forum", "voir un sujet", "liste des sujets", "accueil de l'administration" etc.. Et en ce qui me concerne, je trouve que c'est beaucoup plus organisé et lisible, donc gain de temps pour d'éventuels débuggages.

Perso, je suis plus basé sécurité.
Comme je tiens au serveur, je n'utilise pas les templates
Chaque page a son lot de html, le tout est un hybride parfois peu lisible (j'en conviens) mais souvent facile à s'y retrouver.
La structure-type serait:

\
|-classes
|-designs
|-javascript
|-images
|-logs
|-imager.php
|
functions.php
defines.php
mysqler.php
includer.php
head.tags.php
top.php
foot.php
(autres pages...)
/

Chaque page ne peut être inclue par accès distant grâce à un petit système simple mais performant (plus avancé pour la connexion sql).
mysqler est une classe SQL simplifiée, dont le principe de base est inspiré du tuto "Simplifier le SQL avec une classe" (même si le tuto en lui-même complique trop la classe... bref).
imager contient les fichiers de créations graphiques, images celles des images prédéfinies, et chaque autre dossier contient... Ben c'est explicite

Là où, par contre, je mets du temps, c'est sur la modélisation des données (conception des tables SQL en particulier), mais j'y arrive bien

Et que pensez-vous de l'utilisation des Framework pour développer son site ?

Avantages ?
Désavantages ?

Je réouvre ce sujet qui m'intéresse beaucoup et que je n'avais pas encore vu.

Pour répondre à la question d'avant, l'avantage des framework et en générale la facilité, la rapidité à programmer et en général si ce dernier est bien fait la stabilité et le fait que c'est assez complet. Après les désavantages d'un framework c'est que souvent il y a beaucoup de choses qui sont gérés et que nous n'avons pas forcement besoin ce qui en général alourdit le site, de plus on ne comprend pas vraiment ce que cela fait dans le fond sauf si on a pris du temps a voir comment fonctionne le framework.

En ce qui concerne le sujet original du site, voici ce que j'utilise comme architecture.
Tout d'abord mon arborescence de base

• index.php
• accueil.php
• config.php
• config_sql.php
• cache.php
• Pages/
• Logs
• Administration/
• Includes/
  
  • Scripts/
  • Templates/
  • Fonctions/
  • Classes/
  • Javascript/
  
  
• Css/
• Images/

Je pense pas qu'il soit necessaire de détailler chacun de ces repertoires, maintenant je vais vous montre comment tout cela est organisé.

La page index.php redirige vers accueil.php, je la met toujours si jamais je veux mettre une introduction a mon site, pour un evenement spéciale par exemple

La page accueil.php inclut le fichier config.php, c'est ce fichier qui fait toute la gestion de mon site

Mes liens sont de le forme www.monsite.com/index.php?page= ou www.monsite.com/index.php?script=
Il y a deux liens différents car je differencie deux choses :

La première est l'affichage des données ce qui ce fait par page=
La seconde est la gestion des données (modifications, suppression, insertion) ce qui ce fait par script=

Tout est gére dans le fichier config.php dont je vais vous présenter la structure :
Code : PHP - Afficher / masquer les numéros de ligne

Cette gestion des pages permet d'avoir par exemple un titre personnalisé par page, ensuite le fichier cache.php contient deux tableaux qui regroupent les informations des scripts et des pages
Pour chaque page on a : Le lien de le page, Le nom complet, l'abreviation utilisé, les css utilisés et d'autre informations suivant le site (exemple : un niveau de sécurité dans le cas ou certaines pages doivent etre lus par des utilisateurs enregistrés)
Les scripts contiennent eux de base ces informations : Le lien, le nom complet, l'abreviation, la page de retour par défaut, le message de retour par défaut et autre informations

Ensuite dans l'affichage je n'ai plus grand chose a faire, tout est a peu prés effectué.

Si vous avez des questions n'hesitez pas, personellement aprés pas mal d'année a coder en php j'utilise maintenant tout le temps cet méthode c'est peut être pas la meilleur mais elle a de nombreux avantages, il me reste plus qu'a y inclure une gestion des templates et je pense qu'elle sera trés complète. Cependant je vais peut être poussé la séparation de l'affichage et des actions en adoptant un modele MVC que l'on peut retrouver dans le Zend Framework.

pour moi c'est :

• index.php
• admin.php
• config.php
• cache/
  
  • filariane/
  • templates/
    
    • Un_template
      • un_fichier_par_pages_du_template_compilé
    
    
    • etc ...
    
    
  • users/
  • quelques_fichiers_de_cache_non_classés
  
  
• files/
  
  • admin/
    
    • forum/
    • general/
    • posting/
    • template/
    • ...
    
    
  • forum/
    
    • index.php
    • post.php
    • topic.php
    • topic/
      
      • add.php
      • del.php
      • viewTopic.php
      • ...
      
      
    • post/
      • add.php
      • del.php
      • ...
    • etc ...
    
    
  • site/
    • pas_encore_fait
  • quelques_fichiers_générales_au_site.php
  
  
• images/
  • smilies/
• includes/
  • contants.php
  • functions.php
  • functions_admin.php
  • sessions.php
  • start.php
  • js/
    • fichiers_javascript
• langs/
  • lang_english/
  • lang_french/
• libs/
  • template.class.php
  • sql.class.php
  • mysql.class.php
  • pgsql.class.php
  • sounds.class.php (pour le captcha sonor)
• templates/
  • Un_template/
    • css/
    • html/
    • images/
  • etc ...
• uploads/
  • avatars/
  • images/
  • ...

Du moins, c'est comme ça pour l'instant, ça risque beaucoup évoluer car il est toujours en développement.

Je me mets à Symfony

On pourrait pas scotcher ce thread. Il est pas mal intéressant

Citation : Emacs

Symfony exploite repose sur le modèle MVC, tu peux également regarder prado(soft) qui lui utilises le postback (que je trouve bien plus pertinent).


Tracker.

Est-ce pertinent d'utiliser un Framework si on bosse seul ? Selon moi pas, cela demande beaucoup de temps car il faut aller modifier pas mal de fichiers pour une simple modification.
Puis le gain de temps je crois qu'il doit approcher du néant...

Citation : mikaweb

??!!
As-tu déjà utilisé un framework ?


Tracker.

Je driais même plus pour un framework : ca dépend de l'utilisation, et surtout, y'a même une perte de temps parfois... Car beaucoup trop de choses sont gérées par celui-ci !

Citation : Talus

Utiliser un framework requiert un apprentissage, personne de dira le contraire, mais cette période ne peut en aucun cas être assimilé à une perte de temps. Cela reviendrait à dire qu'apprendre les api php est également une perte de temps. Ce que vous ne mesurez pas c'est le gain infini ensuite.

C'est sûr que c'est chiant de lire des docs, c'est d'ailleurs la raison pour laquelle une grande partie des developpeurs php commencent/continuent à produire n'importe quoi, et puis c'est tellement plus valorisant de réinventer la roue (en moins bien forcement).

C'est quand même étrange de constater que php est l'un des seuls languages où la production/utilisation de framework est la plus faible et la moins fédéré, à mon sens c'est strictement dû au faible niveau de compréhension du développeur lambda.


Tracker.

Tracker -> Un framework peut te bloquer durant la conception, de plus il en existe pléthores, si on regarde bien.

Et où est le problème de ne pas en utiliser ?
C'est sûr qu'il faut savoir ce que l'on fait, et c'est pas donné à tous, apparemment. Mais avec ou sans framework, on peut produire de l'efficace, ce qui est, au final, l'objectif.

Pour ta dernière phrase, je dirais plus que c'est dû au fait que php est rapidement accessible, coté notions et base, voilà tout.

Le problème de ne pas en utiliser un c'est de compliquer la tâche inutilement.
On est dans un monde où l'on doit programmer vite et bien.
Et le meilleur moyen d'y arriver est d'utiliser un framework.
Sans framework, je te mets au défis de produire de l'éfficace aussi rapidement qu'avec un framework.

Avec Django, tu peux monter un site complet en moins d'un Week-End.

Pour ce qui est du sujet du topic.
Avant que je n'utilise un framework.

J'avais un truc dans le genre :

• admin
  • index.php
  • modules
    • news
    • livredor
    • forum
    • upload
• medias
  • skins
    • dreams
      • styles.css
      • images/
    • cables
      • styles.css
      • images/
  • jscript
• modules
  • news
  • livredor
  • forum
  • upload
• index.php

Pour fabriquer les url => URL REWRITING
Pour charger les modules, index.php et l'administration des modules index.php.
Chaque module comprend un fichier nomModule.xml qui donne toutes les informations nécessaires (icône dans l'administration, nom du module, dossier de templates)

Chaque module est indépendant.
Il a ses propres tables, il n'y a juste que le module de base (droits utilisateurs, espace admin, espace membres) qui sont géré par le module de base. J'étais parti sur cette idée pour réaliser Simpleet (Il y a un bon début de code pour les intéressés).

Bonne continuation

Citation : Lpu8er

C'est faux, à part symphony, prado, zend framework et quelques implémentations du modèle MVC, le reste c'est des solutions hyper restrictive, du moins très orientées (cms, e-commerce, blog, forums, etc...). Pour moi la seconde catégorie n'est pas assimilable à un framework, d'ou la limitation évidente lors de la conception.

Côté accès aux données, c'est pas mieux, à part ezpdo ou propel qui eux implémentent véritablement de l'or/mapping, les autres se contentent de faire des couches d'abstraction, bref, le monde php est pauvre en comparaison de l'univers Java, alors que les buts sont les mêmes...


Tracker.

Moi je préfére Python avec le fameux framework Django ou Ruby on Rails pour les sites web. Java c'est bien trop lourd.

Citation : Natim

C'est drole d'avancer ce genre d'arguments, et en même temps ne proposer que des languages interprétés...


Tracker.

Citation : Natim

Désolé, mais t'a tout faux. Comme je l'ai dit précédemment (et comme l'a repris Lp8er), totu dépend du cadre d'utilisation. Soit tu as besoin de toute la fioriture qui accompagne le framework, ou tu dois *presque* apprendre tout un langage pour faire... du php (c'est comme les tpls :p), soit tu n'a besoin "que" de deux trois trucs, que tu peux faire en deux deux, sans tout charger le truc qui peut être extremment lourd. Je sais pas pour les autres langages, mais en PHP en tout cas, ben... Voilà quoi.

"On est jamais mieux servi que par soi-même."

Actuellement, ma manière d'organiser mon site ressemblerait plutôt à ceci (a ne pas prendre à la lettre, car mes vieux sites que je n'ai pas encore refaits sont beaucoup moins bien organisés ):

À la racine, se trouve tous les fichiers, comme index.php, news.php, mais aussi les fichiers d'admins, protégés par un système de sessions.

Dans un dossier /includes ,je met config.php (pour se connecter à la BDD), fonctions.php (toutes les fonctions du site) et common.php (un fichier qui gère le système de session et inclut les 2 autres, que j'inclus dans toutes les pages). Dans ce dossier se trouve également d'autres fichiers à inclure, qui me servent de templates.

Dans le dossier /design, je met tous les fichiers nécéssaires au design (je sépare le CSS "statique", et le CSS de ce qui est parsé en général). Je met également toutes les images statiques dans un sous-dossier /design/img/

Puis après, différents dossiers en fonction de mes besoins.

En gros, cela donne ça :

• index.php
• news.php
• admin_index.php
• admin_news.php
• etc...
• /includes
  • fonctions.php (inclus dans common.php)
  • common.php (inclus dans toutes les pages, gère les sessions, la connexion au SGBD, etc...)
  • config.php (inclus dans common.php)
  • haut.php (template)
  • bas.php (template)
  
  
• /design
  
  • design.css
  • parser.css
  • /img
    
    • logo.png
    • etc...
• /images (varie beaucoup en fonction du projet)

En ce qui concerne l'organisation des scipts en eux-même, je passe beaucoup par des variables telles que $_GET['action'] dans les fichiers.
Par contre, aucune séparations des requêtes ou quoi que ce soit. je sais qu'au niveau de l'organisation, ce n'est pas ce qu'il y a de mieux, mais mes sites sont touts petits, donc ça n'en vaut pas vraiment la peine.

Voici mon architecture du moment :
Citation

J'utilise aussi pas mal de classes statiques (dont deux super importantes définies dans start.php : Une qui me permet d'acceder de n'importe ou aux instances de mes objets, et une autre à mes variables "globales", necessaire pour que tout fonctionne. Mes variables "système" en gros.)

Bonsoir, étant en train de faire une section de mon site pro en php, je regarde comment faire les arborésence et c'est vraiment intéressant. Néanmoins j'hésite à m'aider d'un framework... étant donné que ca fait juste quelque jour que je me suis mis a php. Je pense essayé les framework pour comprendre ce qu'est vraiment le php et ensuite modifier a la main. Ca fait une semaine que je code tout à la main, je commence a avoir compris des choses maintenant lol

J'avoue ne pas avoir tout lu mais de ce que j'ai lu ca ma donné envie de participer et de vous présenter la façons dont j'organise mes sites, voici donc l'arborescence :

Dossier "Root"

• Root

Sous dossier

• + bdd
• + cache
• + langues
• + librairies
• + templates

Fichier

• - index.php
• - bas.php
• - bas.ini.php
• - haut.php
• - haut.ini.php
• - apropos.php

Sous dossier "BDD"

• bdd

Sous dossier

• Aucun

Fichier

• - .htaccess
• - config.xml

Sous dossier "cache"

• cache

Sous dossier

• Aucun

Fichier

• Tout les fichiers mis en cache.

Sous dossier "langues"

• langues

Sous dossier

• en
• fr

Fichier

• - langues.xml
  Contient la correspondance entre le nom complet et le repertoire de chaque langue.

Sous dossier d'une langue

• +langue
• --fr

Sous dossier

• templates
  Contient un fichier par design afin de mettre des infos comme le nom et une description pour chacun.

Fichier

Un fichier correspondant à chacun des modules comprenant des clef de langues. Ainsi qu'un fichier liens qui permet la traduction des urls pour chaque modules.
• - index.xml
• - haut.xml
• - bas.xml
• - apropos.xml
• - liens.xml

Sous dossier "librairies"

• librairies

Sous dossier

• Aucun

Fichier

Toutes les bibliotheques (même si j'ai pris l'habitude d'appeller ça librairie).
• - cache.class.php
• - config.class.php
• - news.class.php
• - xml.class.php
• - ...

Sous dossier "templates"

• templates

Sous dossier

Un dossier par design
• Test

Fichier

• - Aucun

Sous dossier d'un template

• +templates
• -- Test

Sous dossier

• css
  Contient tout les fichiers css du design.
• images
  Contient toutes les images dont le design a besoin, ainsi qu'un sous dossier drapeaux pour les drapeaux de langues (un drapeau par langue).
• js
  Contient tout les fichier de javascript dont le design pourrait avoir besoin.
• xml
  contient le fichier de configuration du design. Celui ci définit certaines choses, entres autres le nombre de news à afficher ou le chemin de l'image de préview du design.

Fichier

Un fichier correspondant à chacun des modules comprenant la partie design avec le moins possible de php (surtout des boucles et des echos donc).
• - accueil.tpl
• - haut.tpl
• - bas.tpl
• - apropos.tpl

Voila c'est l'arborescence que je me suis faite, si vous voulez plus d'informations n'hésitez pas.

Bonsoir ,

Alors moi j'ai complètement restructuré le site sur lequel de bosse, voici ce que ça donne .

Architecture des dossiers

Code : Autre - Afficher / masquer les numéros de ligne
PS : J'en ai pompé pour faire ça .

Fonctionnement

J'utilise la méthode d'include dite « dangereuse », c'est la première fois que je l'utilise et c'est bien je trouve . Tout d'abord j'ai codé un système que je nomme « résolveur d'URL », celui-ci a pour tache de parser l'URL que le visiteur a soumise. Tout d'abord les URL se présente ainsi :



On envoie tout ça (sauf l'extension qui est retirée dans la règle de Rewrite) comme paramètre au script core.php via $_GET['url'], ensuite le script va parser ça en deux parties (au niveau du '~'). La première contient la page à appeler, et la seconde les arguments séparés par des '-'. Je dispose ensuite d'un Array qui fait la conversion de la page => script à exécuter ; par exemple 'accueil' va appeler le script 'mod/news/accueil.php', 'admin-news' => 'mod/admin/news.php'. Et les arguments sont contenus dans un array $_args.

Script d'exemple

Par exemple voici le script 'newTopic' du module 'forum'

Code : PHP - Afficher / masquer les numéros de ligne


Voilà .