Reprise du message précédent :

 
et bien non  
 
je lis souvent des tutos qui disent qu'en mvc la vue PEUT directement interroger le modele.  
 
ce que je fais moi c'zest comme tu dis , c'est ma vue qui demande a mon controler qui demande au modele qui renvoie au controller qui renvoie a la vue  
 
et voila le soucis .  
certains appellent ca nTIERS , d'autres appellent ca mvc
C'est du mvc par definition mais j'ai l'impression que c'est plus contraignant que le concept de base mvc .  
 
or je ne vois pas d'autres maniere de faire. ///

Si tu parles de la vue produite, i.e. la page web en elle même, oui dans du MVC web c'est quasi impossible que la page HTML accède directement au modèle PHP sans être passée par un contrôleur, vu que toute requête HTTP va passer par un front controller. Même en AJAX finalement on va passer par un contrôleur.
 
Après si on parle de la vue dans le sens le template qui va générer la page HTML, pendant la génération de ta vue oui c'est possible d'accéder au modèle directement. Même si finalement dans plusieurs framework MVC web c'est le contrôleur qui se charge d'envoyer les objets du modèle à la vue. (dans Zend Framework et Ruby on Rails au moins)
 
EDIT :
n-Tiers et MVC c'est totalement différent. Par essence, un application PHP n'est jamais vraiment n-Tiers. n-Tiers c'est avoir 3 couches : Persistance - Application (= Serveur) - Présentation (= Cliente). On dit n-Tiers car on peut avoir plusieurs éléments dans chaque couche.
 
Par exemple je bosse sur une application n-Tiers, on a un serveur applicatif en C++, la persistance est assurée par un SGBD Oracle, et comme clients on a un client lourd Windows en C++, et des multiples client léger Web en PHP/ASP.NET/Ruby.
Tout les clients passants par le serveur applicatifs qui reste le point d'entrée universelle dans le système d'informations.

 
Sources

 
cf :

La vue interroge le modèle, mais ne le commande pas.

Non. Le contrôleur n'est pas un intermédiaire entre la vue et le modèle.

 
Le controller instancie le modèle, le refile à la vue, qui y récupère des données.

La vue demande une génère une action, mais juste une demande d'action, le controleur va faire le bordel au model, et ensuite le controleur peut notifier la vue que quelque chose a changé.

même pas...en théorie la vue observe le modèle, qui la notifie donc elle-même qu'elle a changé.

...mais bon tout ça c'est difficilement applicable au web, hein...je connais pas un framework qui ne mélange pas joyeusement le controleur et la vue...

La théorie n'impose pas que la vue observe le modèle, elle peux, mais pas elle doit.    
 
Un pattern observateur-observé en Web je ne sais pas trop comment on peut l'implémenter sans passer par un contrôleur, alors que chaque requête HTTP va passer par le "front controller".
Après si t'as trouvé une solution, nous sommes tout ouïe.
 
 

Avec un MiddleWare ? :]

Cf mon message suivant, en web de toute manière tout est mélangé la plupart du temps, entre le contrôleur et la vue. Ton "front controller" est typiquement un bout de vue, normalement. Avec controller dans le nom, on est mal barrés.

Ce topic donne pas très envie de passer ses applis en MVC
Y a-t-il au moins deux personnes ici qui partagent une vision commune de ce qu'est le MVC ?

 
Il y a 2 camps sur le topic : ceux qui parlent de ce qu'est censé être le MVC, et ceux qui parlent de ce que font les frameworks qui se disent MVC.

En même temps on est dans un topic Web/PHP...
 
On ne peut pas ignorer que le Web nous oblige une certaine implémentation du MVC.

On n'est absolument pas obligé d'implémenter ça comme le font zend ou symfony.
Et il y a aussi différentes manières d'utiliser ces derniers.
 
On pourrait par exemple très bien imaginer un système qui réinstancie automatiquement la dernière vue affichée, pour lui demander de traiter la requête de l'utilisateur (et oui, tout ce qui concerne http devrait être dans la vue...un contrôleur qui interroge $_REQUEST et fait des redirections http on est déjà loin d'un MVC...).
Elle traduirait la demande de l'utilisateur au contrôleur, lequel ferait faire au modèle ce qu'il faut en conséquence. Le modèle pourrait enfin s'il y a lieu prévenir la vue qu'il a changé, et charge à la vue de se réafficher ou de demander à une collègue de s'afficher...
 
Bref, on peut imaginer tout un tas d'implémentations, avec un peu d'imagination. Ca ne veut pas forcément dire qu'elles seraient plus pratiques à utiliser ou qu'elles respecteraient parfaitement MVC, mais il n'y a pas une seule alternative - il y a seulement une implémentation-type qui a été adoptée par les principaux frameworks php, même si elle ne respecte pas vraiment MVC.

Jusqu'à présent tu n'as qu'exposé que des idées vagues et brassé du vent.  
 
Si tu pouvais juste proposer une fois quelque chose de concret qui pourrait tendre à prouver que ce que tu exposes est possible et réalisable...
 
On peux le faire d'après toi, mais il n'y a aucun exemple concret...

 
Bien sûr, je vais écrire un framework complet et poster le code ici, attends 2 minutes.
 
Je laisse tomber, t'es trop borné pour essayer de comprendre ce qu'on te raconte...j'ai déjà dépensé beaucoup trop d'énergie à essayer de te faire écarter un tout petit peu les oeillères qui t'empêchent de voir autre chose que ce que tu pratiques avec zend...

 
Zend Framework, Symfony, Ruby on Rails, ASP.NET MVC, etc.

Du calme jeune homme Ce topic sert surtout à un débat d'idées. On va pas forcément poster des implémentations concrètes (qui peuvent être très longues, ou qui peuvent ne pas être postées car closed-source)

Bah une implémentation basique doit se faire en 1h, 2h grand max.
Moi je ne vois pas comment on peut intégrer le MVC "proprement" par rapport au fonctionnement du web.
 
Le MVC s'applique bien plus au GUI non ?

LALALALALA
 
Je serais peut-être moins catégorique là-dessus Surtout à cause de comment ça fonctionne
 
A la base de la redirection pour moi y'a surtout un controller qui passe le relais à un autre. Et ça doit se passer via redirection.
 
Maintenant je conçois aussi que la vue d'un controller pourrait rediriger ailleurs.
 
I feel conflicting emotions...

Ouaip.
 
Enfin dans pas longtemps via les WebSockets (grâce auxquels le serveur peut pusher des données), on devrait arriver à faire du presque vrai-MVC.

WebSocket qui pour le moment n'est plus implémenté à cause d'une faille dans sa conception même

 
Sans parler d'implémentation basique ou complète, détailler un peu comment techniquement il serait possible de réaliser cette piste serait pas mal. Car on peut toujours tout imaginer...
 

 
Disons que si une autre possibilité existe, au lieu de dire simplement - "C'est faux !" où "Ça ... c'est pas bien." - qu'on propose quelque chose d'un peu plus concret que des idées en vrac pas analogique au MVC classique implémenté dans les clients lourds.

 
http == vue. C'est tout.  
Si tu veux pouvoir changer la vue sans toucher au reste, tu ne peux pas avoir de redirection http dans le contrôleur. Sinon tu lies ta couche Controleur à ta couche Vue - ce que font tous les frameworks web.

Changer la vue ? Tu peux détailler, c'est vague.

Au lieu d'une interface web, tu veux une interface "client lourd", au pif.
C'est aussi ça le but du jeu avec MVC, pouvoir intégralement remplacer une couche en interne sans pour autant avoir à toucher les autres.

Là tu confonds avec l'architecture multi-tiers je crois.

Non. La séparation des couches elle n'est pas là pour faire joli hein...s'il y a des liens forts entre les couches, tu n'en as plus réellement, ça revient à faire une application monobloc...

Oui enfin dans ce cas, même les VRAI VRAI MVC ne vont pas.
Prend une application .NET, tu peux changer la vue pour y mettre une vue web et donc en faire un site web ?

 
Aucune idée, j'ai jamais touché à .net.
Mais si tu ne peux pas refaire intégralement la vue sans toucher au contrôleur, c'est pas du VRAI VRAI MVC, comme tu dis.
Si le contrôleur touche à l'interface utilisateur, tu as un gros soucis...toucher à http dans un contrôleur c'est à ça que ça revient. Ca fait partie de l'interface utilisateur.

Le contrôleur peut demander à la vue de s'afficher.  
 
Après qu'elle le fasse dans un navigateur, un client lourd ou en remplissant un fichier csv ça ne devrait avoir aucune incidence sur le contrôleur ou le modèle.

Je pense que tu vois un peu trop dans l'extrême
Que l'on puisse utilise du XML, RSS, Atom, à la place du HTML là d'accord

Je vois pas en quoi ça empêche de changer la vue ?

Non, je pense qu'il a parfaitement raison. Idem pour la redirection. Même si tu utilises une redirection serveur, il y a une communication avec le client. Donc c'est la vue qui s'en occupe.

Mais ce problème de redirection serveur n'est qu'inhérent à la technologie employée. Pas possible de faire autrement en HTTP normal.
 
Dans mon cas, si on se place un peu au-dessus, j'ai un controller qui après une opération transfert l'exécution à un autre controller. Et le seul moyen ensuite de faire ce transfert est de passer par une redirection HTTP. Je pourrais théoriquement transférer en interne, mais on aurait le problème du refresh + l'URL pas bonne.

 
Si tu as besoin de changer l'interface utilisateur, il faut que tu demandes à la vue de le faire...une redirection HTTP, c'est envoyer l'utilisateur vers une autre vue, c'est tout. Comment la vue se démerde pour traduire ça à l'utilisateur n'a rien à foutre dans le controleur...

Bah en soit, conceptuellement parlant c'est faisable en PHP (je viens d'y réfléchir lol).
 
Mais on perd l'intérêt d'avoir juste une vue très épuré car contenant par exemple que du HTML, tandis que si on mettrais en place le principe pure du MVC il y aurait à minima tout une entête de gestion des évènements.

Faudrait déjà que tu définisses exactement quel est le périmètre de la partie "Vue" pour toi en Web.
 
Parce que des fois tu nous parles d'HTTP - des fois de page Web - des fois on est encore en PHP et tu nous parles de templates...