Hmm si j'ai bien compris le MVC, pour prendre un exemple concret si je suis la structure d'une pseudo frame avec un fichier index.php?action=xxxx constitué comme ceci (de façon simplifiée) :

<?php
$action = $request->get('action');

$view= $frame->include('model/' . $action . '.php');

$template->print('view/' . $view. '.html');
?>

c'est du MVC ?

c'est un peu plus compliqué que ça quand même, ce sont surtout des lignes directrices, la mise en forme dans le code lui-même est secondaire : http://fr.wikipedia.org/wiki/MVC

Le modèle ne sais rien de la view ou du contrôleur. Il doit fonctionner indépendamment du contexte. Donc on peut réutiliser les mêmes actions de modèle dans différentes contextes.

Voici un extrait sur wikipedia:

En résumé, lorsqu'un client envoie une requête à l'application, celle-ci est analysée par le contrôleur, qui demande au modèle approprié d'effectuer les traitements, puis renvoie la vue adaptée au navigateur, si le modèle ne l'a pas déjà fait.

Le concept que j'utilise est que le modèle ne renvoie en aucun cas une vue.

Alors sous quelle forme sont les données transitantes du model au controller ?

Alors sous quelle forme sont les données transitantes du model au controller ?

Bon, je vous écrit maintenant comment moi j'ai résolu le problème.
Voici un exemple comment on appel le modèle à partir d'un contrôleur pour recevoir les derniers articles publier:
Paramètre de l'action:
1.nom du module
2.nom de l'action
3.array qui passe des variables vers l'action

La variable de view $this->viewVar['latest_articles'] pour le résultat est passer par référence dans l'action de modèle. La même action peut aussi être utiliser dans un contexte de contrôleur rpc, soap, cli ou même a partir d'une autre action du modèle.

Je suis en train d'apprendre cette notion de design pattern MVC. C'est pas trop simple ...

Ni a-t-il pas de standards pour le type et la forme des données intermédiaires (transitantes entre les couches) ?
Car si on doit pouvoir placer n'importe quelle vue après, il faut une homogènéïté entre les informations de façon à avoir un modèle (pas celui du MVC lol) simple.

J'ai regardé un peu tes sources Atur. Je ne vois pas d'observer. Est-ce qu'il n'y a pas ? Si oui, est-ce gênant ?

Mince l'orage arrive, jvais lâcher l'ordi ...
Merci pour tes réponses.

Ni a-t-il pas de standards pour le type et la forme des données intermédiaires (transitantes entre les couches) ?
Car si on doit pouvoir placer n'importe quelle vue après, il faut une homogènéïté entre les informations de façon à avoir un modèle (pas celui du MVC lol) simple.

Je ne suis pas sure si je te comprend bien. Vaut mieux préciser.

J'ai regardé un peu tes sources Atur. Je ne vois pas d'observer. Est-ce qu'il n'y a pas ? Si oui, est-ce gênant ?

Non il n'y en a pas.

Quand j'ai commencé à travailler sur ce système je ne savais rien sur mvc. Plus tard j'ai remarquer qu'il y a des ressemblances. Mvc m'a aidé a modifier mon code et de séparer les couches. Donc mon approche mvc était celle de la porte de derrière et est différemment de celle d'autres systèmes qui essaie de mettre la théorie en pratique, que je trouve parfois très (trop) compliquer.

Heu... c'est quoi tes abbréviations là à la fin ? Wink

Les charsets.

Merci

Pour revenir sur le MVC, je pense avoir compris grosso modo le concept. Après si on applique à PHP, en gros voici ce que je comprends :
- la méthode c'est l'ensemble des classes qui traitent avec les bases de données, fichiers ou autres, et effectue des calculs dessus
- la vue ce sont les templates
- le contrôleur c'est le script lui-même, qui appelle dans tel ou tel ordre les méthodes des différentes classes en fonction des informations reçues de l'utilisateur

Suis-je dans le juste ou non ?

Merci

Pour revenir sur le MVC, je pense avoir compris grosso modo le concept. Après si on applique à PHP, en gros voici ce que je comprends :
- la méthode c'est l'ensemble des classes qui traitent avec les bases de données, fichiers ou autres, et effectue des calculs dessus
- la vue ce sont les templates
- le contrôleur c'est le script lui-même, qui appelle dans tel ou tel ordre les méthodes des différentes classes en fonction des informations reçues de l'utilisateur

Suis-je dans le juste ou non ?

Oui, c'est une implémentation basique et simpliste mais tout-à-fait suffisante dans la plupart des cas. Au boulot j'ai récemment réutilisé un package «MiniMVC» que j'avais réalisé il y a fort longtemps et qui correspond à cette implémentation simpliste, c'est très facile à réaliser, en fait on a globalement 3 classes :
- un contrôleur à qui on passe un nom (le nom du contrôleur) et une action (qui permet de spécifier le modèle et la vue) avec une méthode run() qui se contenter de faire $model->run(), puis $view->run($model->variables)
- un modèle avec un nom complet qui donne le script à inclure quand on appelle run(), et une méthode set() (ou mieux : __set() ) pour définir les variables qui seront ensuite passées à la vue par le contrôleur.
- une vue qui dans mon cas est une surcharge de la classe Smarty.

C'est vraiment très très basique, et très insuffisant pour dire qu'on a un «vrai MVC» mais ça permet de séparer clairement les couches en interdisant toute communication directe entre modèle et vue (à aucun moment la vue n'a accès au modèle ni le modèle n'a accès à la vue, le modèle prépare des variables, le contrôleur les récupère et les passe à la vue, tout passe par le contrôleur).

Bonjour,
Un problème que j'ai rencontré avec quelques frameworks mvc est que une demande est liée à une action du modèle. Mais dans la plupart des projets c'est rarement le cas. Prenez la page d'entrée d'un projet web. Souvent il se passe beaucoup sur une telle page: affichez des news, les dernier article, la navigation, etc. Si on regarde dans les forums des frameworks c'est une discussion que vous trouvez souvent.

La j'ai pris un autre chemin. Une demande est liée a un contrôleur de page. Dans ce contrôleur on définit comment réagir sur la demande et de suite communiquer avec les (plusieurs) actions du modèle.

Quand je regarde votre petit débat sur le MVC, ca me fait penser a mon projet en cours
J'ai constitué un core avec toutes les classes qu'il fait (db, template, cache, session, chargeur de modules) et après, a l'aide du chargeur de module, j'analyse l'url et en fonction de l'url je charge le module adéquat.
Chaque module posséde un fichier xml de définition des actions via un indice numérique et permet aussi de vérifier les variables GET requises.
Ensuite, j'instancie le module qui est en fait une classe du même nom que le module et mon run() est en fait un __construct() qui fait un switch de la variable contenant l'action pour appeller la méthode désirée
Ca peut ptet paraitre bizarre pour certains, mais c'est très pratique
@++

J'ai encore quelques questions

Déjà, Naholyr, est-ce que tu pourrais m'envoyer ton miniMVC que je puisse regarder le fonctionnement. Il me faut un exemple simple.
Je comprends très bien le principe maintenant, mais j'ai encore du mal à me visualiser tout ça sous forme de code. Merci d'avance.

Après, une autre question qui va peut être me faire passer pour un con, mais j'ose ^^ (même pas peur !) : est-ce qu'on peut faire un design pattern MVC en PHP 4 ?
J'ai commencé à développer mon Framework en PHP 4, et j'aimerais ne pas passer tout de suite à PHP 5.

Une dernière chose : appliquer un modèle MVC sur un Framework ne sert à rien ?
Prenons l'exemple de mon package Mail. Je construis le mail en fonction des paramètres des méthodes (une pièce jointe, un sujet, un corp texte ou HTML etc.). Est-ce qu'on doit y inclure le MVC ? Pareil pour le package XML, en ce qui concerne le Parser, je ne vois pas l'utilité d'y appliquer un dp MVC.
Ce que j'essaye de comprendre, c'est à quoi s'applique le MVC exactement. C'est juste lors de la construction du GUI, le front-end ? Le MVC n'a pas sa place dans le fonctionnement d'un Framework (sauf pour les paquetages qui construisent de l'HTML ou autres). En fait, le MVC n'a sa place que dans un CMS ?
J'avoue être un tantinet perdu ... Mais je compte sur vous pour être mes petites lampes hehe (qu'il est mignon ...)

Merci pour vos réponses.

Déjà, Naholyr, est-ce que tu pourrais m'envoyer ton miniMVC que je puisse regarder le fonctionnement. Il me faut un exemple simple.

Je suis preneur aussi à l'occasion

Après, une autre question qui va peut être me faire passer pour un con, mais j'ose ^^ (même pas peur !) : est-ce qu'on peut faire un design pattern MVC en PHP 4 ?
J'ai commencé à développer mon Framework en PHP 4, et j'aimerais ne pas passer tout de suite à PHP 5.

oui

Ce que j'essaye de comprendre, c'est à quoi s'applique le MVC exactement. C'est juste lors de la construction du GUI, le front-end ? Le MVC n'a pas sa place dans le fonctionnement d'un Framework (sauf pour les paquetages qui construisent de l'HTML ou autres). En fait, le MVC n'a sa place que dans un CMS ?
J'avoue être un tantinet perdu ... Mais je compte sur vous pour être mes petites lampes hehe (qu'il est mignon ...)

Merci pour vos réponses.

MVC est just un structure, architecture selon laquelle tu construit une application. Ca n'a rien avoir avec le type de l'application (cms ou n'importe) .