Reprise du message précédent :

C'est normal c'est du PHP
 
Et c'est un cas un peu spécial, vu que cette View peut être récursive et doit d'auto-appeller
 
Si t'as d'autres idées

 
Donc pour toi c'est pas du template ce qui suit :
 

 
non. Ca c'est un mélange de controller et de model.

 
Alors comment tu isolerais ca ?  

tu gicles le model de là, et tu as un simili controller...

J'utilise:

• Pas PHP
• Des moteurs de templates existants

Ben moi j'utilise PHP comme moteur de template... Là c'est juste la classe au-dessus qui se charge de sélectionner les données adéquats à partir du model, et de créer les sous-view s'il faut. Alors évidemment la gueule du constructeur est plutôt moche, mais c'est pas trop grave, les paramètres étant injectés

non

Toute la partie SQL devrait être déplacée dans un objet modèle, et ce fichier devient plus ou moins un contrôleur qui s'occupe

• De recevoir et dispatcher les requêtes
• D'instancier les modèles et de leur transmettre les données reçues via les requêtes
• De transférer les objets modèles au(x) template(s)

Ca t'embeterais de prendre mon exemple et de l'adapter selon ton exemple ?

Lis le tout premier post du topic, ça te donnera une idée. D'ailleurs je vais le refaire un peu un jour

 
Si tu pouvais refaire ton 1er post en incluant un systeme template ce serait bien

Ben y'a un système de template A l'arrache, mais y'en a un

et ca ?
 

C'est un peu mieux. Maintenant le get_user devrait se faire dans une classe séparée qui appellerait ensuite la template en elle-même

C'est un truc de ce genre je pense dont parle FlorentG.

 
Tu pourrais détailler ? je vois pas trop la

Bien, re-exemple complet. Certains trucs devraient évidemment être implémentés differemment (genre la connection à la base, qui n'a évidemment rien à foutre dans getUser), mais c'est pour le principe :
 
Model

 
Ensuite vient le Controller, qui va instancier le model et le filer à la view :
 

 
La view, composée d'une classe et d'une template :

 
Et enfin la template

cool

Chuis pas d'accord avec la partie template (et une partie des fonctionalités du contrôlleur)
 
Le modèle user devrait être une simple classe User, avec un truc genre find ou findUser en méthode statique, qui prend un ID et renvoie un objet User, et le template ne devrait pas avoir besoin d'aller chercher lui même le user, toutes les données devraient lui être fournies point barre.
 
Donc on aurait un truc du style:
 
user_controller

class user_controller {
     // le dispatching est fait plus haut dans l'application, un contrôlleur n'a pas à se taper les $_GET ou $_POST
     public function GET($id) { 
       $user= User::find_by_id($id);
     
       return new user_view($user);
     }
}

 
user_view:

class user_view {
    public function __construct($user) {
        require('user.template.php');
    }
}

user.template.php:

<div class="user">
    <span class="name"><?php echo $user->name ?></span>
    <span class="id"><?php echo $user->id ?></span>
</div>

Tout dépend de la DP que tu veux : Domain, Active Record, DataTable, etc.
 

Ca dépend de quoi... Parfois je préfère juste filer le model, et la view se démerde avec. Le Controller fourni un model et quelques infos, et après on peut switcher la view comme on veut.
 
Exemple réel dans mon framework, j'ai un Controller Diaporama qui met à disposition un model Diaporama. Ensuite j'ai fait plusieurs View : une qui affiche photo par photo, une autre qui affiche la listes des photos avec celle en cours en grand au-dessus. Y'en a une qui a besoin d'une seule photo, l'autre qui a besoin de la liste complète. Ce serait dommage de devoir refaire un deuxième Controller (ou une deuxième action) juste pour supporter la view.
 
Alors je créé un model, j'le met à disposition. Ensuite dans le fichier de config j'indique la view (photo par photo ou liste), et le framework s'occupe de lier controller et view. Et comme dit, le Controller reste le même quelque soit la view...

Ca semble tellement logique et clair comme concept que personne n'arrive à se comprendre ou expliquer clairement les choses    
 
Pas mal pour une méthode censée simplifier, c'est un peu comme le concept de "l'extreme programming" non ?  

J'explique pas assez clairement ?

En surfant HFR, je suis tombé sur un topic qui citait cet article : http://tahe.developpez.com/web/php/mvc/
 
Je l'ai mis en oeuvre dans une application qu'on m'a demandé de faire récemment en PHP. Je trouve que la structure est pas mal.
 
Tout d'abord, on a un fichier de conf qui stocke :
- les associations entre les noms des actions et les scripts php contenant les actions a effectuer (1 script php par action),
- les associations entre les noms des états et les scripts php contenant les états ainsi que les actions autorisées à être executées à partir d'un état,
- les associations entre les modèles de vues et les scripts php chargés d'effectuer le rendu d'une vue,
- les associations entre les noms des vues et les templates à utiliser par le modèle de vue (ici, Smarty),
- les associations entre les noms d'actions et les droits d'accès (ça, c'est pas dans l'article, c'est de moi).
 
Ensuite, on a le contrôleur (index.php) qui :
- desserialise les variables de session,
- reçoit le nom de l'action à executer,
- vérifie que l'enchaînement d'action est autorisé,
- vérifie que l'utilisateur a le droit d'executer l'ation,
- appel le script php d'action pour l'exécuter,
- appel le script php d'état spécifié par le script d'action.
 
Le script d'action exécuté fait ce qu'il a à faire :
- analyse les paramètres passés en entrée (formulaires ou autre),
- utilise les objets pour manipuler la BD,
- stocke les erreurs rencontrées,
- spcécifie le script php d'état et la vue à afficher pour la réponse.
 
Le script d'état :
- charge les traductions dont la vue a besoin,
- indique les JavaScripts et feuilles de styles dont la vue a besoin,
- refait un peu de mise en forme si nécessaire de certains données (notamment les objets) pour qu'elles soient exploitables par le moteur de template,
- charge dans des "buffers" les données dynamiques (ce qui a été calculé par le script d'action),
- demande de serialiser la session.
 
Le script de modèle de vue :  
- initie Smarty,
- réalise les affectations entre les variables du template et les traductions/données/Javascripts/CSS,
- appel le template et affiche le rendu.

A mon sens, la vue ne fait que récupérer des infos du model, elle ne lui en donne pas.
(alors que toi tu fais :
$this->data['user'] = $model->getUser($userId);
dans la vue, la vue donne donc le paramètre $userId au model)
 
Pour moi, le controller doit passer le $_GET['id'] au model, passer le model à la vue, et la vue récupérer les infos du model ; bref, la vue ne lui en donne pas.

Je suis en train de survoler là, ça m'a l'air assez bordélique, et pas beaucoup automatisé

 
qu'est ce que tu entends par "automatisé"? L'idée principale, c'est que l'application est vue comme un automate à états finis.

Vu la gueule de la config
 
 
Enfin ch'ais pas... Ou alors c'est developpez.com, chaque fois que je lis un article sur ce site, soit c'est n'importe quoi, soit y'a chaque fois des erreurs

le fichier de config est effectivement à rédiger manuellement. L'avantage que j'y vois est qu'on ne risque pas de voir son appli se retrouver dans un été non prévu. En plus, si on a modélisé dans les specs l'enchaînement des pages via un graphe, ça correspond bien à la structure du fichier de config : les états+vues sont les sommets, arêtes sont les actions...

Le truc c'est qu'on peut automatiser tout ça...

si on utilise un outil pour modéliser le graphe de l'appli, effectivement, ça pourrait générer le fichier de conf automatiquement.
 
l'avantage aussi du fichier de conf, c'est que ça évite d'avoir un gros switch dans le contrôleur sur l'action a effectuer...là, directement, la bonne action est exécutée

Moi j'ai pas de switch, tu spécifies l'action que tu veux, si elle existe elle est exécutée, et si elle existe pas ça part vers l'action par défaut...

ben dans le contrôleur mis en exemple sur la première page, y'a un switch.

Je pense que si l'on veut faire quelque chose de propre en MVC, mieux vaut s'inspirer d'un projet open source mature qui utilise ce genre d'architecture. On peut par exemple prendre Xoops comme modèle.

Ouais, c'est mis en exemple après de mon côté j'ai fait différemment, c'était un peu pour illustrer... Je vais d'ailleurs une fois mettre à jour l'exemple

Ouais, j'ai pas mal étudié des trucs genre CakePHP, CodeIgniter ou le ZendFramework. J'ai des trucs qui ressemblent beaucoup, d'autres moins. J'me suis aussi pas mal baladé sur le forum de sitepoint, où plein de gens discutent de ce même sujet

Bonjour
 
Comment faites vous pour integrer des sessions utilisateurs avec droits dans un model MVC ?
Exemple connu, l'administration de news.
Prenom une action listeNews
Un utilisateur classique vois la liste des news alors qu'un utilisateur connecté peut avoir ou non X droits (comme editer, modifier, supprimer) sur cette même vue.
Comment intégrer cela ?
Ma vue listNews contient les liens (comme édition), mais ils s'afficheront en fonctionne de certaines variables qui seront passé par le model listNews donc.
Mon model News biensur est la pour gérer les news, mais comment marche la liaison, avec, premierement, les sessions, et deuxièment avec le model utilisateur ?
 
Qui crée le model utilisateur qui représente l'utilsateur connecté ? le controlleur ? ou est stocké ce model ? car, n'importe qu'elle action peut en avoir besoin...

C'est le controlleur (ou plutot le FrontController s'il y en a un) qui gere les utilisateurs et les actions qui leurs sont autorisees.

 
C'est à ce niveau là que j'ai mis aussi cette gestion. Ca me apraît le plus logique et le plus centralisé...

Désolé, mais j'ai du mal à vous suivre.
Donc, en admettant que le front controlleur lis des variables de session de l'utilisateur, crée le model qui va avec, comment il le passe à l'action demandé ? Ou alors, c'est l'action qui demande au front controlleur l'utilisateur connecté et qui donc peut déterminer bon liens de la vue ?
 
Autre chose, en admettant toujours cela, c'est donc, le front controlleur trouve une action non autorisé, il va donc être obligé de chargé une vue spécial dites 'opération refusée' ? J'ai l'impression qu'on s'éloigne du model MVC car, on a un front controller qui fait tout
 
Je veux bien que le front controlleur concerve un model utilisateur et que les actions lui demande, mais après, j'aurais tendance à dire que ce sont les actions qui gère et décide de renvoyé la bonne vue. D'ailleurs, les actions peuvent-elles tous être capable de renvoyé une meme vue ? (genre une vue "opération refusée" ) ?

Selon moi, le contrôleur intercepte les actions demandées par l'utilisateur. Si celui-ci n'a pas les droits, le contrôleur, qui normalement aurait dû appeler l'action demandée, peut très bien en appeler une autre : "action refusée". Cette action renvoie donc une vue qui affiche, par ex, un message d'erreur.