J’ai enfin compris pourquoi je ne comprenais pas. En l’occurrence, j’avais du mal à capter la définition du contrôleur.

Merci de nous avoir fourni une définition claire, efficace et sans ambiguïté : « Le contrôleur, c’est tout le reste. »

Si un hébergeur le desactive, faut quitter l’hébergeur, c’est un con.

Je suis d’accord que l’hébergeur est un con mais si t’as payé ton hébergement et que tu dois le quitter le lendemain juste pour ça, ça vaut pas le coup. Du coup si on veut rendre notre code le plus portable possible il vaut mieux éviter. À noter que les short tags ne sont plus désactivables depuis PHP 5.4, mais évidemment ça rajoute une dépendance sur une techno assez peu déployée (http://www.php.net/manual/en/ini.core.php#ini.short-open-tag) Aucune idée pour la syntaxe alternative.
Le mieux reste encore de ne pas faire de PHP et se mettre à Python :)

Au temps pour moi sur l’aspect non web de l’exemple Python, j’ai écrit trop vite sans faire attention. Ce que je voulais dire c’est que l’exemple c’est du “one shot” : tu l’exécutes et la vue n’a plus à se mettre à jour ensuite contrairement généralement à une interface graphique. Mais je comprends parfaitement que ça sorte de l’objectif de présenter simplement MVC, je voulais juste apporter une précision dans les commentaires :)

@herison : restons dans un truc qui est utilisable au quotidien. L’arbre, à pars le bruler pour se tenir chaud…

@agateau : ok, je corrige ça.

@raphi: voit le de cette magnière : si tu dois générer un PDF, tu vas pas avoir de template. Du coup ta vue elle est où ?

@MrAaaah: merci pour la correction. Et effectivement, j’ai dis une connerie. C’est une forme de séparation des responsabilités et du rendu / vs modèle, mais c’est pas du MVC. Y a de l’observer, de l’entity, etc.

@Marien : ok je vais mettre ça à jour. Par contre la syntaxe alternative, si on a pas de moteur de template bien entendu, c’est vachement plus facile à lire. Si un hébergeur le desactive, faut quitter l’hébergeur, c’est un con.

Quand à l’aspect Web, l’exemple en Python n’est pas Web…

Sinon c’est un peu dommage de se concentrer sur l’aspect web même si je comprends bien l’intérêt. Comme dit herison plus haut, le MVC pour les clients lourds est différent du MVC web en ce qui concerne la gestion de la vue. Je n’ai jamais trouvé de bon article expliquant bien tout ça (jamais vraiment cherché peut-être aussi…)

Et pour reprendre la discussion à propos des jeux vidéo, vu sur LinuxFR une alternative qui est à priori plus adaptée : les systèmes à entités (http://linuxfr.org/news/je-cree-mon-jeu-video-e01-les-systemes-a-entites)

Sinon petite coquille au niveau de la partie du contrôleur :

Dans notre cas le programme a besoin d’un code qui :

Importe notre contrôleur vue et notre modèle. :

@Recher & @Sam : Le modèle MVC me semble pas très répandu dans les JV, après je sais pas comment ça ce passe pour les gros projets.
On a plutôt tendance à tout garder bien indépendant et updater chaque composant séparément (moteur physique, affichage, logique du jeu, réseau, inputs, etc.) quand il est temps. Par exemple on ne rafraichit pas une IA aussi souvent que l’affichage. Après t’a es cas (notamment UDK il me semble) où tout les objets du jeu sont dans des threads indépendants.

Niveau organisation du code, pour avoir fait 4-5 projets avec UDK et Unity3d (projet de 48h à 15 semaines) j’ai jamais croisé de modèle MVC (du moins jamais sous la forme que je connais). Par contre dans les deux y’a une utilisation massive des composants.
(j’ai pas de grosses connaissances des designs pattern ni dans la conception d’un moteur de jeu, donc je dit p-e des conneries sur certains points ^^)

(bon petit choix de musique au passage, mais le top c’est ces démos avec Razor1911)