Reprise du message précédent :

Décris nous la bonne solution s'il te plait...
Parce que les "C'est nul !" sans explications, ça n'as jamais avancé à grand chose.

Déjà si t'arrêtais de penser à un implémentation MVC fait en Java/.NET/Qt où on a directement tout ce qu'il faut pour faire du callback/observateur-observé/signaux.
 
Comme dit, déjà si tu nous disais quel est, en Web, le périmètre de la Vue, du Contrôleur et du Modèle, ça serait un grand pas en avant.
Parce que quand on clique sur un bouton, le navigateur fait toute logique, et pour moi un "submit" HTML n'est que comme un évènement un support pour notifier le contrôleur de l'action.
Après le contrôleur agit à propos de cet évènement, comme le ferais un handler dans un client lourd...

Bof, ça en fait gagner quand t'as 3 contrôleurs qui se battent en duel, dès que c'est un peu plus complexe, ou que t'es plus tout seul sur le projet, ou que tu dois maintenir un truc écrit par quelqu'un d'autre (genre toi il y a 6 mois) c'est une source d'emmerdes. Et quand tu tentes de faire un truc pluggable ou réutilisable, c'est même pas la peine.

Je préfère largement des mappers explicites à la urlconf (Django) ou Routes (Rails, Routes):

• Ça offre un point d'entrée clair dans l'application: tu regardes le dispatcher racine, ça te donne une vue du brol, des infos sur la manière dont c'est conçu (bien ou mal, selon la propreté et la clarté des routes), etc…
• C'est composable, d'autant plus parce qu'il y a habituellement support pour du grafting (tu peux ajouter un autre routeur bindé sur un préfixe donné)
• Ça découple les bindings et les controllers (nommage comme chemin physique, même si ceux-ci peuvent être imposés par ailleurs ou socialement), ce qui facilite la réutilisation des controllers (cf generic views, tu fais pas un site avec ça mais c'est génial pour démarrer) ou même l'intégration de modules complets dans ta structure (tu peux binder l'admin django à une URL arbitraire de ton site, t'es pas forcé de la foutre dans /admin)
• Ça rejoint le point précédent, mais ça permet de binder le même contrôlleur sur plusieurs URLs différentes (potentiellement avec des custos, le controller pouvant être partiellement dynamique dans son implé)
• Ça supporte des opérations d'altération: une extension peut habituellement altérer des routes existantes, avec de l'autodiscovery (ou un dispatcher bindé directement sur le controller genre Flask) quand c'est possible c'est en allant bricoler dans le bas niveau du dispatcher, généralement dans des coins pas prévus pour.
• Enfin au fur et à mesure que ton site évolue, ça simplifie la gestion des anciennes URLs (elles vivent au même endroit que toutes les autres) et ça évite de bouger une partie du comportement de ton appli dans le fichier de conf d'un serveur (ou 3 ou 4 selon la flexibilité de ton déploiement ou tes prévisions du futur) pour sa réecriture d'url

Et un bon mapper d'URL pourra trivialement reproduire une résolution automatique (mais pas l'inverse). Genre avec routes tu ajoutes la règle

map.connect(None, "/{controller}/{action}" )

et toutes les URLs pas matchées vont mapper sur une action {action} associée à un controller {controller} (Routes s'occupe juste de l'interprétation et du reversing des URLs, c'est le framework qui décide de ce qu'il fait des infos fournies par Routes. Pylons par exemple va exécuter la méthode {action} sur la classe "controllers.{controller}.{controller}Controller" par défaut)

 
Oui. Mais ce n'est pas ce qui est fait dans les frameworks php.  
Chez eux c'est le contrôleur qui traite les événements utilisateur directement, au lieu de traiter ce que leur envoie la vue.
Si c'est la vue qui envoie les évènements utilisateur au contrôleur, faire partir la chaîne du contrôleur n'a pas de sens...d'ailleurs pour moi ton dispatcher fait partie de l'application, c'est un élément de la vue.

Mais concrètement ça apporterait quoi de faire du MVC orthodoxe comme ça ?

Bah j'ai ça aussi On peut hériter d'un Controller pour reprendre ses fonctionnalités ailleurs. Les controllers, models et views peuvent être groupés en module, surchargeables aussi.
 
Genre j'ai une espèce de lib standard avec un module gestion de contenu, dont je peux hériter dans un site et customiser à donf : surcharger complètement des fonctionnalités, en proposer des nouvelles, etc.

Bah voilà, t'es obligé de créer des controllers hérité alors que ça n'a ni sens ni logique.

map.connect(None, "/{controller}/{action}" )

 
Dans Rails aussi c'est l'URL qui définit le contrôleur. Les routes sont qu'un ajout possible, mais c'est facultatif.
Dans Zend Framework c'est comme ça aussi par défaut, et la seule chose qu'on a à connaitre c'est la convention prise.

être dans le bon topic.
Et une séparation des couches qui permet effectivement d'en changer une sans changer les autres...même si ça ne doit arriver qu'à un projet sur 10 millions, sur du web.

Ah oui bien-sûr, ça n'a ni sens, ni logique J'aimerai bien la connaître ta super logique tiens  

Je laisse un peu tomber la séparation ultime pour un truc plutôt pragmatique...

Voilà Pour l'instant j'ai pas eu spécialement besoin de routes spéciales. La mapping URL-controller suffit pour l'instant. Si un jour j'en ai le besoin, je rajoute les routes. Pour l'instant c'est YAGNI et KISS qui priment

On est d'accord

Même si bon, dans ta logique, le côté "web" n'est pas inhérent au projet mais seulement à la vue, donc ça pourrait servir à pouvoir transformer facilement une appli web en appli bureau ou autre, non ?

 
C'est le principe. Mais la tendance est plutôt à l'inverse.

Et sauf cas extrème, c'est pas un mal

Tu m'étonnes...installer un soft sur 300 postes a jamais été mon objectif dans la vie...

Destination le clouuuuuud

Ah non hein, on a déjà assez de branlette marketing avec MVC, pas besoin de saupoudrer une couche de cloud là-dessus, pas de buzzword bingo ici!

 
ok merci  
 
donc dans ce que je suis en train de faire c'est viable , mon archi n'est donc pas foireuse .  
cool.  
j'adore ce topic .

Elle est ou la logique de devoir hériter d'un controller et créer une classe supplémentaire juste pour binder la même chose sur une URL différente?

Au final, fait quelque chose qui fonctionne et qui te fait gagner du temps...

C'est pas un seul controller, c'est un ensemble de controllers, models et views. Le mécanisme d'héritage était le plus simple à mettre en oeuvre. Enfin j'vais pas me lancer dans une complète explication de mon archi.
 
Pour ce que je fais et mes besoins, ça fonctionne parfaitement bien.

[post édité car inutile]
L'ORM, c'est génial

Je comprends pas ce que ton approche apporte de plus par rapport à Symfony ou Django ou n'importe quel FW

J'ai lu vite, mais j'ai l'impression que t'as juste réinventé le concept d'ORM

J'ai googlé ORM et effectivement c'est exactement ce qu'on a fait sans savoir que c'était une approche déja formalisée
Bah je ferais dodo au lieu d'écrire un post aussi long la prochaine fois  

ah voila

C'est quoi les framework qui roxx en ce moment pour faire du web ?
Toujours symfony/django ? Autre chose ?

drupal ?

Drupal c'est un CMS, pas un framework

arf laule

 
CodeIgniter 2 est bien sympa aussi.

Zend Framework et Symfony 2 à priori pour le PHP. L'ASP.NET MVC monte pour ceux qui bien sur aime l'éco-système Microsoft, etc.
 
Après ça dépends ce qu'on cherche exactement, son niveau en développement/développement web, etc.
 
 

Je suis en train de dev une application de génération de contenu pour Netvibes et iGoogle.
 
A chaque dashboard on peut associer plusieurs modules. J'ai donc un modèle Module et des sous-modèles tels que Blog, Wiki, Twitter, etc.
 
Pour la génération du XML, je me demandais si je le faisais dans le controlleur Dashboard ou bien dans le modèle ?
J'aurais tendance à dire dans le modèle.

Génération de XML => dans le modèle Le controller ou la view ne doivent même pas savoir qu'il y a de l'XML en-dessous, on doit pouvoir interchanger avec autre chose

Ptet passer par une factory pour ça ?

 
Ouais, ptet.
Parce qu'il faut générer soit pour iGoogle, soit pour Netvibes.

Ça dépends, si c'est du XML pour envoyer au WS de Google, c'est différent.
 
M'enfin je verrais plus ça dans une couche service la communication avec les WS.

 
Ehoh, c'est du MVC, j'ai 3 couches

Tu y tiens, à ta couche service qui existe pas, toi, hein...

Alors si ça te fait plaisir au lieu de l’appeler "Service_Netvibes" tu l’appelleras "Model_Service_Netvibes", mais ça reviendra juste un peu au même...
 
Autre solution, simplement le mettre dans sa Library si c'est très générique et réutilisable.

 
Model et Netvibes dans le même nom de classe, ça sent la séparation des couches de qualité.