Discussion :

[icl1c]

Bonjour,

j'aimerais avoir votre avis concernant l'arborescence de mon projet. Ce projet doit suivre un pattern MVC, utiliser Smarty pour les templates ainsi qu'être multilingues avec gettext.

+/
../models/
............/module1.m.php
............/module2.m.php
../controllers/
................./module1.c.php
................./module2.c.php
../tpls/
........./templates/
......................./module1/*.tpl
......................./module2/*.tpl
........./templates_c/
........./cache/
../locale/
.........../fr_FR/
..................../LC_MESSAGES/
.........../en_EN/
..................../LC_MESSAGES/
../include/
............/js
............/jquery
............/css
............/images
../smarty/
............/internals
............/plugins
../index.php

index.php est mon front controller, il se chargera de répartir les requêtes sur les controllers concernés. Puis affiche le template qui se trouve dans tpls/templates/moduleX/*.tpl

Cela paraît-il cohérent?
Merci d'avance

[Benjamin Delespierre]

Hello,

Il est généralement d'usage de séparer la partie applicative de la partie publique de façon à pouvoir protéger les répertoires sensibles à a donner plus de cohérence à notre arborescence.

Personnellement, j'utilise une arbo proche de celle du Zend Framework:

/application/
+ config/
+ + application.ini
+ + bootstrap.php
+ controllers/
+ models/
+ view/
+ + helpers/
/libraries/
+ unelib/
+ uneautrelib/
/public/
+ scripts/
+ images/
+ templates/
+ styles/
+ index.php
.htaccess

[icl1c]

ok je suis d'accord mais quelle différence tu fais entre tes views de ton dossier /application/ et les templates dans ton /public/ ?

et ton bootstrap.php te sert à quoi? car mon "bootstrap" c'est l'index.php.

[icl1c]

Bonjour,

Je me pose une autre question concernant les contrôleurs. Comment structurez vous vos contrôleurs? est-ce un immense switch case? ou utilisez vous une autre structure?

merci d'avance

[Benjamin Delespierre]

Hello

Désolé de pas être venu plus tôt, je suis pas mal pris en ce moment.

Dans le MVC, il est primordial de bien comprendre le rôle du routeur: c'est lui qui en fonction de la demande du client va appeller le(s) bon(s) controlleur(s). Cela se fait généralement au moyen de routes prédéfinies, regarde du coté de CakePHP, il fait ça très bien tu peux t'en inspirer.

Un contrôleur caractérise une route, une section si tu préfères, et ses méthodes caractérisent des actions. Par exemple, pour poster un commentaire sur un article, on pourra avoir: monsite.com/article/xxxx/post (forme réécrite de
monsite.com/index.php?rt=article&act=post&id_article=xxx).
Coté PHP tu aura un contrôleur "ArticleController" qui porte une méthode de classe "post".
Généralement, on affecte une action par défaut à tous nos contrôlleurs, le moyen le plus simple d'avoir une structure commune est de passer par une classe abstraite "BaseController":

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
abstract class BaseController {
 
  protected static $_request;
  protected static $_response;
 
  abstract public static function index (); // action par défaut
 
  final public static function setRequest (Request &$request) {
    static::$_request = $request;
  }
 
  final public static function setResponse (Response &$response) {
    static::$_response = $response;
  }
}
 
class ArticleController extends BaseController {
 
  public static function index () {
 
    $list_articles = Articles::list(0,10);
    return compact('list_articles');
 
  }
 
   public static function post () {
 
    if (static::$_request->email, static::$_request->comment) {
       $result = Article::create(static::$_request->email, static::$_request->comment);
    else $result=  false;
 
 
     return compact('result');
   }
}

Le routeur va alors récupérer le retour du contrôleur qu'il à appellé et va passer tout ça à la vue pour l'affichage.

[icl1c]

D'accord je vois, ma vision du contrôleur est différente de celle que tu as donné. J'ai déjà utilisé le framework symfony donc je comprends très bien le système de route. Tu as un contrôleur par classe toi.

Moi ma vision (beaucoup plus simpliste) était plus du genre, un contrôleur pour un module du style :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
$action = secure($_GET['act']);
switch($action){
case "post" : 
   traitement...
break;
default : 
    traitement ..
}

et mon "routeur", soit index.php. Il vérifie que le module demandé existe bien, puis charge le contrôleur correspondant. Et c'est dans les contrôleur que je vais vérifier l'intégrité des données avant d'utiliser les méthodes de mes modèles.

car avec ta méthode, je ne vois pas où tu testes l'intégrité de tes données?

dans tous les cas mon but n'est pas de réécrire un framework complet mais juste de bien séparer les M-V-C