Vos techniques pour le développement de sites en PHP

Salut, vous parlez de mettre les requetes séparé du code...

c'est à dire que chaque " $retour = mysql('requete sql') or die (mysql_error()); " sera dans un fichier php à part ?
Et quand on en aurait besoin on l'appellerais avec un include ou require ?


En parlant d'include,
C'est quoi la différence entre include, require et require_once ?

TheCereal-Killer » Déjà la plupart du temps la BDD est gérée par une classe, sinon pour la méthode des requêtes séparée je pense que c'est juste le SQL qui est mis à part et après on peux faire :
Code : PHP
Par exemple.

Citation : TheCereal-Killer
Si include échoue une E_USER_WARNING est renvoyée, si require plante il renvoie une E_USER_ERROR, et require_once test si le fichier n'a pas déjà été inclus si oui alors il renvoie une erreur .

Ok, merci pour ta réponse sur les include

la plupart du temp la bdd est gérée par une classe ?
Code : PHP

Donc, après je devrais remplacer 'inserer_message' par envoyer_mp ou liste_news... ?

J'ai jamais trop bien compris l'utilité des classes... en fait :s Si quelqu'un pourrait me montrer un petit exemple de classe qui gère la bdd, ca serait gentil... (avec une requete INSERT TO et une SELECT, pour que je cerne bien la différence... ;p
La seule fois où j'ai entendu parler de classe, c'est dans le tutos pour utiliser du xajax

TheCereal-Killer => regarde dans les tutos, y'en a un sur la création d'une classe de gestion de bdd (MySQL)

Citation : Bilbax

Presque vrai

Sauf que pour *_once, si le fichier a déjà été inclus (ou requis), ca ne l'inclue pas... Sans renvoyer d'erreurs !

Perso quand je dis "séparer le sql", je pense plutôt à un fichier qui se chargera de renseigner une variable avec les valeurs souhaitées.

Par exemple, /lib/livre/get.php peut être créé comme celà:

Code : PHP

J'ai pris l'habitude d'en faire des fonctions parce que je trouve ça plus pratique pour passer les arguments sans risquer de confusions de noms

Le truc qui m'a surpris dans ton organisation, Shepard, c'est de faire "un fichier par action", le fichier étant dans le dossier de la page consultée.

Evidemment, ma première réaction a été de penser : oui, mais si un module est présent sur 2 pages différentes, tu fais comment pour cette action ? (Par exemple, un mini-sondage situé dans le menu, et qui peut donc aussi bien apparaître sur l'accueil que sur le forum. Et pourquoi pas, sur une page spécifiquement dédiée aux sondages, qui l'affichera en plus grand)

A priori, tu fais comme le SdZ, c'est à dire qu'au moment d'effectuer l'action, tu pars sur la page action en question, qui affiche un message d'attente et redirige vers la page d'origine ensuite ? Donc tu aurais :

/sondage/voter.php

Et dans le menu :

method="post" action="../sondage/voter.php"

J'ai l'impression que classer les actions en dossier en fonction de la page perd rapidement de son intérêt dans un site fortement modulaire (Plusieurs modules par page : l'action appartient au module, et non à la page). C'est à dire que même si tu sais sur quelle page se trouve le bug, tu ne sais pas pour autant où le chercher (Et c'est le but de ton organisation de savoir ça, je crois).

Enfin bref, ça parait quand même une bonne chose, même si personnellement je déteste avoir trop de fichiers Un fichier qui fait une seule action, ça me parait être du gaspillage (Même si au final, c'est plus rapide, tu charges moins de fonctions inutiles). C'est surtout assez bordélique. Je préfère avoir par exemple un fichier qui contient autant de fonctions que d'actions d'un module, et j'appelle la bonne fonction.



Pour l'organisation des pages, je préfère la méthode "une page par script" plutôt que "un index qui inclue tout". Pourquoi ? Parce que ça donne plus de liberté.

Si on a un index qui contient le menu, la bannière, le pied de page, et qu'il inclut le script dans le corps, on aura toujours le même design (Puisque toujours la même page, et que c'est cette page qui choisit le design). De plus, ça oblige à vérifier les includes, et beaucoup croient qu'ils sont sécurisés alors que c'est faux (Ils oublient de vérifier les ../ par exemple, permettant d'inclure à peu près n'importe quoi, y compris des fichiers interdits, ou bien utilisent is_file, qui retournera vrai aussi bien sur "index.php" que sur "http://.../hack.php")

Un fichier page.php, qui inclut le template, en revanche, offre beaucoup plus de liberté. C'est lui qui choisit son design, et si on veut une page simplifiée dans laquelle le menu n'apparait pas, on peut. On peut également choisir un CSS différent pour une page précise. Tout ça, c'est plus compliqué à faire quand on a un index qui inclut tout (Et la seule solution, c'est de modifier ce fichier index.php pour l'adapter au fichier page.php, chose qu'on n'est pas censé faire : on ne modifie pas une page générale pour l'adapter à 300 pages quelconques, au risque de se retrouver avec un switch géant). Bref, je ne crois pas qu'il y ait de solution simple pour avoir une liberté suffisante en n'utilisant qu'un index qui inclut tout le reste. Au mieux, il faut avoir une autre page qui incluera le script désirant un design différent.

Juste par hazard quelqu'un aurait deja utilisé le modèle MVC pour la conception de son site web ???

Pas mal ce sujet
par contre je n'utilise pas de moteur de templates.
Le code php est dans le html à l'arrache
j'ai jamais vraiment utilisé un moteur, et je sais pas comment sa fonctionne ce truc ainsi que les .tpl
Une suggestion ?

merci et bonne journée

Veldryn > J'utilise un index qui inclut toutes les pages (plus facile avec l'URL rewriting) mais il ne gère pas le style, il ne fait qu'inclure la page demandée, spécifiée par le nom du module et l'indice de l'action si elle existe, ainsi que certaines pages communes comme : la page de connexion, la page de gestion d'erreurs et le système de cache avec éventuellement le moteur de template si une des pages n'est pas en cache. Ca me permet également de définir quelques constantes au passage comme la racine, les chemins d'accès aux différents dossiers, les noms de table etc.
La page inclue appelle un template qui gère l'inclusion des CSS et éventuellement l'inclusion de menus ou autres.
Ca peut paraitre assez industriel comme ca mais une fois mis en place c'est beaucoup plus confortable.

Citation : Shepard

Que fais tu de l'Abstraction ?

Perso je deteste avoir plein de pages comme par exemple :

Citation : Shepard
Je prefere avoir une page unique livredor.php et mettre des if(isset($_GET['add'])) C'est tellement plus clair.

Code : PHP

Citation : Aravis
Oui mais plusieurs petits fichiers ne sont pas tous chargés à la fois.
Alors qu'un "gros" fichier prendra plus de temps.

Enfin c'est ma façon de voir. Il y aura plus de ressources prisent dans ton cas. Non ?.

Moui, d'où l'hybridité (en plus comme ca tout le monde est d'accord -.-) !

Citation : Tibrus
Oui enfin je peux largement me permettre, vu mon trafic, de faire des script a rallonge . Trafic qui n'augmentera d'ailleur pas vu le but du site.

Grosso modo, c'est l'intermédiaire entre le fichier centralisé (index?p=machin) et le 1 fichier / action (machin.php, truc.php, etc).

En gros, on découpe le fichier central en plusieurs grandes sections, auquelles on assigne une liste d'actions concernant ces même actions.

Les ressources, c'est au niveau des requêtes qu'il faut chercher à les gagner. Bien sûr, faut pas non plus abuser des boucles inutiles/imbriquées. Mais un code propre, qu'il soit en 1 ou 15 fichiers, ça fera pas de grandes différences pour le serveur.

Pour le SdZ, je sais plus où j'avais lu ça, Homer n'a que très peu de travail, idem pour Bart, tandis que Lisa 2 est toujours saturée quand on approche des 500 connectés (C'est elle qui gère la base de données en lecture : Bart ne fait que de l'écriture, et un peu de lecture pour la recherche. Et c'est ça qui coûte cher, la lecture).

Donc l'optimisation n'est pas vraiment un prétexte valable ici.

Personnellement, j'essaie de regrouper les requêtes, ce qui donne un code parfois un peu trop bordélique : si j'ai 2 modules qui ont 2 actions à faire sur la même table, j'essaierai, si c'est possible, de faire ça en 1 seule requête. Du coup, les 2 modules deviennent très liés, ce qui n'est pas bon en terme de conception (Mais justifiable en terme d'optimisation). Ca rend le code parfois (souvent ) difficile à maintenir

Pour ma part ca se passe comme ca :

-www
|---- admin Tous les fichiers relatifs à l'admin du site
|---- lib Le "pseudo framework" que j'ai dev avec toutes mes classes
|---- includes Tous les fichiers inclus dans les autres pages
|---- images les images visible dans le site
|---- struct Les images relatives au design
|---- lang gestion des langue si necessaire
|---- index.php
|---- page2.php
|---- page3.php
|---- ...

Pas de template donc , mais un petit framework qui accélère sensiblement le dev avec des classes telles que mysql, gestion d'image, gestion d'upload, gestion de zip ... Je colle également la dedans les lib js telles que prototype ou scriptaculous

Moi j'avais fais un site il était comme ca :
./includes -- Contient tous les fichiers inclus (fonction.php, top.php, bottom.php, corps.php...)

./themes -- Contient un dossier pour chaque themes, dans le dossier il y a un fichier index.php, un dossier CSS et un dossier images

./modules -- Contient tout les "modules" du site classé dans des dossiers (Accueil, Forum, News....)

./images -- Toutes les images qui ne change pas (exemple : petite image supprimer, editer...)

./cache -- Tous mon système de cache (un dossier pour chaque module)

./index.php


En gros, ma page index.php appel vital.php (fichier de connexion a bdd, calcul nb en ligne...) ;

ensuite elle appelle index.php du dossier themes/[theme choisi] (ce index.php qui est dans un des dossier de themes appel les menus, le corps, le bottom... (le corps va chercher dans ./module/ la page qu'on souhaite affiché) ;

Et d'autres ptits trucs encore


Voilà qu'en pensez vous ? c'était plutot bien fait ou pas ?
Ma facon de faire pour choisir un design était-elle mieux que d'utiliser un moteur de template (niveau optimisation, praticité...)?


Actuellement je bosse sur un autre site, je viens de commencer et j'ai pas encore bien classer (je pense pas que je vais garder la mm organisation que pour mon premier site)

Bon, ben voilà...
Très instructif ce topic je trouve

Je me permet juste une question en passant :

Pourquoi dans lib créer class.sql.php et pas simplement sql.php ?
Quel est l'avantage de passer par une classe ?
Performence, place, ... ?

Le seul avantage que je vois étant d'après ce que j'ai pu lire l'héritage. Mais je reste un peu sur ma fin.

Autant repatir sur une autre idée en changeant la future disposition de mon site

Dans l'attente

C'est mon avis perso, apres chacun fait ce qu'il veut.Ben je trouve que une class sql est bien plus utile et accélère sesiblement le dev. d'un site avec SGBD, si cette dernière est bien réalisée.

Le tuto sur la création d'une class pour le sql que ma conseillé The Dead Master est très bien expliqué je trouve, je pense que j'ai compris le principe de création d'une classe.

Mais j'ai pas vraiment compris pourquoi il est mieux d'utiliser une classe... (pour le sql par exemple)
Pour l'instant, je continue de dévelopé mon site sans classes, pensez vous que par la suite sa fera beaucoup de boulot pour y intégrer des classes ? (boulot pénible, mais si ca a pour but d'optimiser mon site, je le ferais avec plaisir ^^... )


Et... pour ce qui est de mon arborescence ? elle est bien ou pas ?

À mon tour

Je fonctionne comme ceci:

En refonte

Voilà!

Bye

Tibrus une classe SQL est pratique car tu peux avoir des variables dans ta classe (liste des requetes passées, nombre de requetes passées, etc, etc). Tu peux aussi avoir besoin d'instancier 2 fois ta classe si tu veux te connecter à un 2e serveur MySQL facilement.

En objet c'est bien plus propre qu'avec des global et des if de partout !

Voilà pour moi :

• fr/
• • fr/Designs/
  • • fr/Designs/Nom_du_design/
    • • fr/Designs/Nom_du_Design/Images_design
      • • fr/Designs/Nom_du_Design/Images_design/forum/
      • fr/Designs/Nom_du_Design/includes/
      • fr/Designs/Nom_du_Design/CSS/
      • fr/Designs/Nom_du_Design/JS/
  • fr/Images/
  • fr/index.php
  • fr/forum.php

Bah moi mon site se présente plutôt comme ça :

• index.php
• themes/
  • affichage.php
  • style.css
  
  
• inclus/
  • fonctions.php
  • pages.class.php
  
  
• xml/
  • /* fichiers xml, et triés dans des dossiers */
  
  
• config/
  • config.xml
  • .htaccess
  
  
• admin/
  • index.php
  • admin.class.php
  • affichage.php
  • style.css
  • pages/
    • accueil.php
    • config.php
    • ...
    • ...
    
    
  
  

(J'aimerai préciser que j'ai repris la structure d'un de mes amis : http://heretique.org/)

Salut à tous,

Je me permet de remonter ce sujet qui peut en interesser plus d'un

www/
/application
/controllers
/models
/views
/filters
/helpers
/scripts
/library
/public
/images
/scripts
/styles


Moi c'est un peu près comme ça, normal, j'utilise le framework zend (The PHP Company)

Pour le site que je fais en ce moment, c'est:
-Un dossier principal où sont toutes les pages qui peuvent s'afficher sans dépendre d'autres.
-A l'intérieur, un dossier 'bouts' où sont mes trucs à inclure.
-Un dossier Remplissage pour remplir le site de contenu, pour un blog, une gallery, des news, tout ça...
-Un dossier forum avec le forum dedans
-Enfin, un dossier CSS avec mes feuilles de style CSS.

Bonsoir,

Personnellement, je ne gère pas de gros site, mais plus un ensemble de modules plus ou moins indépendants. De fait, pour une meilleure lisibilité pour l'utilisateur, j'ai préféré créer un répertoire par application (l'avantage, c'est que ça donne des URLs très propres et souvent très courtes, du style "avaricum.org/contact"). La seule contrainte, c'est qu'il faut inclure à chaque fois l'en-tête et le pied de page, mais ça se fait très bien au final.

En revanche, pour un script plus étoffé, j'ai choisi le fichier unique, sans que ce soit finalement très pratique au niveau programmation. Cette technique offre néanmoins plusieurs grands avantages fonctionnels :

• un système d'identification unique : une seule condition d'identification englobe toute la page ;
  Code : PHP - Afficher / masquer les numéros de ligne
  1. <?php
  2. if (is_connected())
  3. { // Le reste de la page accessible en connexion seulement }
  4. else
  5. { // Formulaire d'identification }
  6. ?>
• aucune redirection, technique que je trouve tout à fait impropre : le formulaire d'identification pointe sur l'URL entrée, on peut donc arriver, par exemple, directement sur sa messagerie privée, sa page de gestion des identifiants, etc. ;
• la structure globale est plus facile à changer : pour changer les titres dans toutes les pages, je n'ai qu'à toucher à une ligne, au lieu d'avoir à ouvrir chaque fichier individuellement ;
• et caetera.

Après je pense qu'il n'y a pas de structure fondamentalement bonne ou mauvaise ; la preuve, j'utilise deux modèles différents, qui en définitive s'imbriquent. Mais je considère que cette structure doit être revue s'il existe des URLs à rallonge avec plus d'un argument, par question d'esthétique un peu, mais aussi parce que ça fait vraiment fouillis. Pour pallier ce problème, je préfère utiliser la méthode POST avec des pseudo-formulaires, au moins c'est invisible pour le visiteur.

(Excellente idée ce sujet )

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.