Reprise du message précédent :
Tu vois il faut pas écouter les autres

bon en fait FlorentG j'aimerais bien quelques précisions
En fait je ne suis pas sur d'être d'accord avec ce que tu fais (mais je ne dis pas du tout avoir raison, juste j'aimerais confronter nos points de vue ^^).
 
Résumons : tu fais en sorte que le Controller ne sache pas ce dont a besoin le Model. Et c'est le Model qui vérifie les paramètres qu'on lui fournit.
Mais je trouve que ça ne colle pas avec certains cas :  
 
Exemple 1 :  
On veut voir la liste des utilisateurs d'un site. Le Controller récupère cette demande. Personnellement dans mon projet, pour un truc aussi con, le controller accède directement à la couche bdd. Du style :  

 
Voilà déjà j'aimerais bien savoir comment fonctionne ton Controller quand tu récupères un truc bidon comme ça.
 
Exemple 2 :  
Maintenant, imaginons qu'on veuille voir le profil d'un utilisateur en particulier. Pareil, c'est un truc bidon où il faut juste récupérer l'ID de l'user demandé, et le réupérer à partir de la couche d'accès bdd.

Et là on voit donc qu'avec mon bignouffe, c'est forcément le Controller qui va faire le controle sur l'ID : vérifier s'il y en a un, s'assurer que c'est un entier. C'est ici particulièrement que je ne comprends pas comment tu fais.
Puisque c'est ton Model qui vérifie les paramètres dont il a besoin, à qui demandes tu de faire ça ? C'est ta couche d'accès bdd (ici mon Data_User) qui va faire ce contrôle ? Tu as une classe "intermédiaire" pour faire ce contrôle et renvoyer un objet User ?
 
Voili voilou, besoin d'explications

D'ailleurs, je rebondis sur le deuxième exemple : à quel endroit est-il le plus approprié pour faire des vérifications sur les valeurs des paramètres (de la page) récupérés ?
 
Dans le Controller, parce que c'est lui qui recoit les évènements utilisateurs, ou dans le Model parce que c'est lui qui connait le mieux le type de ses attributs ?

bonne question et c'est aussi l'objet de mon post.
Moi il me semblait logique que ça soit le controller : c'est à lui de récupérer les "input", pour moi ça coulait de source que ça soit lui qui fasse les contrôles. Le model ne se concentre ainsi que sur son boulot, sans se préocupper de la validité de ce qu'on lui balance.
 
D'un autre côté, FlorentG a pas tort, puisque c'est le Model qui doit savoir si le nbre de caractères max pour un nom d'utilisateur c'est 50, ou 100, etc.
 
(de toute façon quoiqu'il arrive, je ne pense pas que qqn ait tort ou raison, étant donné qu'il me semble que les deux possiblilités respectent le principe MVC. La différence se joue au niveau de l'implémentation, et là chacun sa façon de faire. Après, autant chercher à faire au mieux )

En fait pour ce genre de questions, je suis encore en train d'investiguer. Là je suis en train de développer une application, donc j'ai quelque chose de concret. On verra bien où ça mène.
 
Ca me fait penser aussi à truc, c'est que lorsque j'ai une appli à développer, faire de gros design en UML et réfléchir 3 mois sur un problème sert finalement pas à grand chose. Vaut mieux commencer par coder comme un porc, puis refactoriser, c'est là qu'on aboutit à une architecture qui marche.
 
Là pour l'instant mon appli ressemble à un tas de merde bien fumante, avec des trucs dans tous les sens complètement pas cohérents. Mais en refactorisant certaines choses, après avoir vu des cas concret, je commence à avoir quelque chose qui ressemble à un truc bien foutu Donc là je vais développer plein de truc (qui concernent tes questions et interrogations), compte rendu demain

>Ca me fait penser aussi à truc, c'est que lorsque j'ai une appli à développer, faire de gros design en UML et réfléchir 3 mois sur un problème sert finalement pas à grand chose. Vaut mieux commencer par coder comme un porc, puis refactoriser, c'est là qu'on aboutit à une architecture qui marche.
 
clairement, ça fait pas de mal une ptite phase UML pour voir où on va, mais rester x mois dessus, moi personnellement je n'arrive pas à voir concrètement les besoins précis. (si y en a qui y arrivent tant mieux )
 
 
Sinon pour en revenie au sujet, au final je crois que pour le moment je vais continuer comme je fais : le controller récupère les "input" ET les controle, puis les balance au model. Il sait donc parfaitement ce qu'il faut au Model

J'me demande si faudrait, par exemple, que le controller ne soit au courant que de la PK du model, juste histoire de sélectionner un machin... Ou alors c'est la view.... Arghhhh

yopyop  
 
@Djebel1: sur ton exemple 2 c'est bien ton controller qui... contrôle ce genre d'input (typiquement les $_POST, $_GET, $_SESSION,...)
 
Sinon cette discussion est intéressante (très même, pour une fois que ca conceptualise un peu... le nez dans le code c'est bien mais le résultat est pas toujours à la hauteur...), et j'ai déjà -malgré moi- implémenté une version MV (document/view) light (php 4 oblige) pour faire un portail web sur un jeu vidéo, ya maintenant 1 ptite année de ça. Mais c'était au pifomètre, j'ai découpé comme je l'ai senti sur le moment, et bon il faut bien dire qu'avec le temps et les méthodes s'ajoutant, mes classes deviennent un peu lourdes à gérer...
 
Bref, c'est à propos du modèle que je me pose des questions, surtout au niveau des liens avec le SGBD... Parce que le modèle se nourrit beaucoup de la bdd (et inversement), alors je ne sais pas si c'est utile de rajouter une couche entre modele & bdd... On peut imaginer des méthodes d'un UserDataAccess qui utilisent une/des instances d'un UserModel, par exemple, pour gérer les ajouts/modifs/suppressions d'un User donc... Il faudrait pouvoir faire le truc dans l'autre sens aussi (pour le select)...
J'ai lu que certains utilisent une couche DBAccess qui vient se placer en dessous du modèle, ou des modules PEAR déjà tout faits (pour pouvoir passer sur plusieurs SGBD différents), mais j'aimerais avoir un cas pratique (ou déjà une idée de cas) là-dessus...
 
++

Il y en a qui connaissent et/ou utilisent http://jelix.org/ Jelix
 
Ca a l'air pas trop mal et orienté Mozilla (XUL )

j'interviens pour vous parler comment je fonctionne
Reprenons par exemple l'exemple de gestion d'utilisateur.
 
Pour la création d'un utilisateur, j'instencie d'abord une class 'User', puis j'apelle ma fonction 'add' de cette classe en lui passant les valeurs postés (mais non vérifié). Je ne lis jamais mes variables dans mes class.
Ma fonction de classe fait ses vérification, ses traitements. Au final, elle renvoit 'true' ou 'false'
Si elle renvoi 'false', alors, je veux switcher sur différent type d'erreur qu'elle a put générer, par exemple
 

 
 
Pour la lecture, j'utilise l'opérateur de porté '::'

 
Pour l'affichage, j'utilise le moteur smarty, je m'etends donc sur cette classe pour créé une classe plus 'spécifique' à me objets.
 
concernant la bdd, j'ai aussi un class 'bdd', la pluspart de mes classes se crée une instance de Bdd à leur propre instantation.
Meme si j'utilise plusieurs class, le fait que chacune d'elle est une instance de Bdd n'est pas genant, car mysql sait si il y a déjà un lien vers la bdd ou non, et donc, renvoi toujours le même lien. Ca fait un peu comme un singleton. Sauf que je n'ai pas à eut à coder le singleton moi-meme

+1 pour la classe 'bdd', l'idée du singleton est bonne d'un point de vue sémantique, par contre du point de vue fonctionnel MySql est effectivement assez puissant pour savoir s'il existe déjà une connexion, et dans ce cas la rattacher à chaque nouvelle instance de 'bdd' créée.

Hello !
 
Après lecture de ce topic très interessant, j'ai une question :
 
Prenons un exemple précis pour mieux comprendre : MVC appliqué à des News.
 
Si l'on veut ajouter une news, est-ce le controlleur ou la vue que doit s'occuper de vérifier si le formulaire a été soumis afin de vérifier la validité de la news postée (via le modèle) et l'insérer via le modèle ?
En gros : la vue peut-elle utiliser le controlleur non pas pour lire des données mais pour en insérer ?
 
Si non, cela implique de créer 2 modèles pour l'insertion :
* 1 pour le formulaire vierge (ou pas vierge si l'utilisateur voulait rajouter la new et qu'il y avait des erreurs)
* 1 pour le succès de l'ajout
Cela est assez contraignant non ? (et ca "pourrit" le controlleur avec plein de code)
 
Merci à ceux qui m'ont lu et pourront m'éclairer sur la question

Pour moi la question se serait plutôt entre soit le controlleur soit le modèle, la vue ne fait que afficher.
 
Perso c'est le modèle qui s'occupe de ça

J'ai opté pour un modèle passif qui ne sait pas qu'il est utilisé, et qui n'a pas connaissance ni du controlleur, ni de la vue. Ca ne me semble donc pas logique de placer ca dans mon modèle.
Je vais donc mettre le bordel des variables $_GET et $_POST dans le controller et non la vue, et créer d'autres vues pour gérer les erreurs.

C'est ce que j'ai finalement fait.
Cela m'a obligé à créer d'autes vues, mais ce n'est pas grave, c'est seulement des vues à près tout, qui se ressemblent en plus, donc le temps de modification n'est pas très grand.
Merci !

Pour l'interaction Controller - Model au sujet de la récupération et de la vérification des entrées utilisateur, dans mon application actuelle j'ai fait un truc ressemblant fortement à ce que proposait FlorentG.
 
En fait, le Model ne doit pas savoir d'où proviennent les données, ça ne veut pas dire que ce n'est pas à lui de vérifier le nombre max de caractères, etc ...
Dans mon appli, j'ai 8 gros formulaires avec tout plein de champs, qui permettent de "remplir" 8 classes de mon Model.  
Chacune de ces classes possèdent une méthode checkData(), qui va être polymorphe en fonction de la classe. Le Controller récupère le tableau $_POST et le balance au Model par la méthode checkData. Que ces données viennent de POST ou de ce que tu veux, le model s'en tape : la méthode checkData demande simplement un tableau associatif attributs - valeurs, il s'en fout d'où ça vient, ça respecte bien le MVC.
Pour chacun des attributs de la classe, le Model va vérifier la validité des valeurs, et remplir un tableau associatif d'erreur faisant parti de ses attributs si elles sont invalides. La View pourra ainsi récupérer ce tableau d'erreur, et afficher des messages en relation.
 
Mais je pense qu'on peut être souple. Si on reprend l'exemple 2 de mon post un peu plus haut, je continue de faire pareil : j'ai besoin de récupérer un objet, simplement à partir de son ID ? Le Controller vérifie la validité de l'ID, et appelle directement la couche d'accès aux données, pour récupérer l'objet du Model qui convient. Pas la peine de faire compliqué quand c'est simple.
Parce que sinon, il faudrait faire quoi ? Instancier un objet du Model, lui passer l'ID, puis cet objet va aller chercher ses données grâce à son ID ? mouais  

quoi mouais ? moi je fais comme ça, je trouve ça assez logique (enfin c'est logique avec ma logique... ) et pas spécialement contraignant.
C'est bien mon instance d'objet issu du Model qui possède les méthodes utiles pour récupérer les données (directement ou pas, dans le cas d'une couche supplémentaire dédiée à l'accès aux données, on utilise alors encore un niveau supplémentaire d'indirection, et on passe l'ID dans ton cas, m'enfin là ça devient encore + dilué)
 
Et je fais des méthodes comme ça avec chaque attribut simple, couple, triplette,... représentant une clé unique.
Je suis donc capable de récupérer une définition complète de mon instance grâce à n'importe quel matériau (attribut simple, couple,...) suffisamment capable d'identifier mon instance recherchée (de manière unique quoi)

Puneze ici ça branle des mouches  

non mais ça se vaut hein
Je trouve juste que ça fait des étapes inutiles en plus.  
 

ou l'inverse !

Au risque  de dire une connerie ou de répèter, en quoi le contrôleur doit-il passer les données du modèle à la vue ?
 
tu peux très bien faire un contrôleur qui appelle le modèle à bosser (donc récupèrer des données via les DAO, modifier des données entrantes, etc, dans ce modèle les résultats sont sauvegardés dans les membres), il appelle ensuite la vue, qui va piocher les infos parmis les membres du modèle.
 

 
Chez moi le contrôleur récupère toutes les valeurs $_GET/$_POST/etc et les transmet au modèle par une série de variables globales.
je fais un tri rapide du genre :
(on imagine un formulaire d'inscription au forum)
$GLOBALS['NewUserDatas'] qui contient les références aux $_POST des champs de mon formulaire,
comme ça le contrôleur sait où il choppe les infos sans avoir à connaîtres celles qui seront utilisées, et le modèle pioche dans ce qu'il a besoin.
 
Par contre, les $_SESSION/$_COOKIE et cie, je les récupère avec un DAO (perso, ça me paraît logique).
 
J'éspère ne pas avoir seulement enfoncé des portes ouvertes, j'ai survollé très vaguement la première et dernière page.

Là je suis en train de faire une application gratuite, assez lourd et sensible et donc la sécurité ou prévoir m'interesse.  
Que fait ton objet qui gère les données externes ?

Euh, à vrai dire pour l'instant pas grand chose de génial, je fais surtout des assignations/récupérations des variables adaptées à mon cas.
 
Par contre j'ai pas vraiment de tests sui les valeurs, puisque dans les sessions et les cookies je sauvegarde pas de données sensibles.

j'ai jamais dit que le controller devait passer les données du model à la vue hein, on est d'accord à ce sujet  
Ca ferait d'ailleurs du controller un médiateur, ce qui n'est pas son rôle, j'irai même jusqu'à dire que c'est anti MVC
 
Par contre, j'ai dit que c'est le controller qui transmettait les données issues de l'utilisateur au Model. Après y a 50 manières de faire ça (comme ce que tu proposes, ou ce que proposes FlorentG, ou ce que je propose)

Je n'en vois pas bien l'intérêt. Outre le fait que si ton appli un jour est mise sur un serveur avec le register global sur on, ça pourra éventuellement poser des gros problèmes de sécurité (edit : bon non en fait c'est con cette remarque, vu que de toute façon ça vient de l'utilisateur et doit être sécurisé).  
A mon avis, que le controller fasse :  
$_GLOBAL['donneesUtilisateur'] = $_POST;
ou que le controller fasse :  
$objModel = new Model_Object;  
$objModel->checkData($_POST);
 
C'est pas beaucoup plus compliqué.
Mais bon, chacun fait comme il préfère

Nan, mon contrôleur balance pas ça aussi directement, il fait quelques tests avant (sinon c'est clair que c'est de la surcharge pour rien).
 
après, l'intérêt serait de vider les variables dans le cas d'un register_globals à on.
Mais perso, j'aurais plus tendance à developper une application qui ne démare volontairement pas dans le cas d'une configuration de php aussi moche.
 
Et finalement, je vois pas en quoi les problèmes de sécurités seraient plus nombreux avec ma méthode qu'une autre.
 
L'utilité de cette méthode est de séparer "mieux", les données reçues :

remarque, ce truc est bien aussi, puisque ça passe aussi (et automatiquement) par référence.

Say ! Say ! Say ! Say !
 
Me revoilou
 
Bon alors j'ai super-beaucoup avancé, mais pas beaucoup en même temps
 
En ce moment, je suis en train de revoir l'architecture des Controller, et surtout le mappage URL -> controller, histoire d'avoir du mod_rewrite pour zéro dollars (sans avoir à changer le .htaccess à chaque fois).
 
 
Au niveau architecture du Controller, c'est plutôt standard : fonction pour chaque action, préfixée de la méthode HTTP :
 

 
Alors on a par exemple l'action "add" : soit elle est accédée par GET (affichage du formulaire d'ajout), soit par POST (ajout dans la base). Ca simplifie beaucoup de chose, et ça colle super-bien au protocole HTTP. Ainsi, si on accède à l'action "delete" par GET, une erreur "405 Method Not Allowed" est renvoyée, on respecte bien le protocole (interdiction de supprimer quelque chose par GET, vu que ça fout un bel effet de bord).
 
J'essaye toujours de bien coller aux recommandations, du coup ça me paraît un peu obligatoire de bien respecter le protocole HTTP. Aussi, je peux par exemple définir une action pour la méthode PUT, et avoir genre un p'tit logiciel pour uploader des fichiers (comme chez Flickr).
 
 
Viens ensuite le mappage des URLS. Ce que je voulais, c'est de belles URL, mais sans avoir à modifier chaque fois le .htaccess. Alors l'idée, c'est ça
 

 
Et on utilise une URL de ce genre :

 
Le framework pige que l'action possède trois paramètre, et les assigne : on retrouve dans $year la valeur 2006, dans $month 06, et dans $day 04. Et ça roulze, mod_rewrite automatisé
 
Pour l'instant ça marche plutôt bien !
 

Hum. Dans ce context, comment t'en sors-tu si tu veux dupliquer une section de ton site? Exemple: le module de news "publique" et un autre module de news auxquel seul les personnes enregistrées ont accès. Ou, dans un autre style, comment gères-tu un système qui contiendrait des sous-éléments emboités mais sans niveau maximum d'emboitement (un peu comme un forum ou on rajoute des sous-catégories et des groupes par après.)
 
Questions subsidiaires: Elles ont quelle gueule tes rewriteRules? comment gères-tu les extension non .html? si par exemple je veux puiser directement certaines images dans un répertoire et en générer d'autres à la volée.

Ca j'ai pas encore fait, mais le plus logique sont des access-list : tel utilisateur peut lancer telle méthode ou non...
 
Pour l'emboîtement après, ben je vois pas trop le problème
 

Alors elles sont toutes bêtes, ça ressemble à :

Ainsi, j'ai quelques dossiers pour du contenu statique...
 
Notons que j'ai encore quelques trucs qui sont pas encore clairs Mais pour l'instant ça marche zuper-bien.

J'pourrais aussi tester si le truc est un fichier qui existe ou pas... Bref, plusieurs solutions valables.
 
Je crois que j'ai piqué cette idée chez CakePhp

Pour l'access-list, ça n'est pas aussi simple, vu que c'est la même méthode qui peut ou non être utilisée par un utilisateur suivant le contexte. Pour l'emboitement, vu ta rewrite rules, ce n'est effectivement pas un problème car tu te paluche le parsing des "/" à la main, mais mon but était d'éviter de le faire avec php. Sinon, je ne suis pas trop fan de ta manière de rediriger les choses, cela implique que des fichiers statiques de différents modules ne sont pas proprement isolés, et il me semble même que l'on pourrait facilement la contourner pour accéder directement à des pages php sans le dispatcher.

Ben les fichiers des différents modules sont pas trop accessibles comme ça... Pareil pour les pages php, on peut pas faire grand chose

Ca a l'air sympa tout ça FlorentG. Et pour les url ça me semble tout à fait bien pour un truc que je recherchais à ce sujet
 
Mais je dois dire qu'au niveau du controller, j'ai opté pour la structure frontcontroller + command pattern.
Les bénéfices d'un frontcontroller dans ton application sont tout simplement magiques, un seul et unique point d'entrée à toute ton application.
 
Ensuite j'ai des objets commandes possédant tous la même interface, pour être utiliser par le frontcontroller indistinctement. Ca pourrait coller à ta structure généraliste (getIndex, getAdd, postAdd), mais personnellement, je trouve ça bien bien dur de tout faire avec de telles méthodes généralistes. Donc mes objets commandes possèdent une bête méthode execute(), et dedans les différentes actions possibles sont déterminées par une variable $_GET['page'].

En fait, si j'ai choisi de séparer en fonction getIndex, getAdd, etc., c'est pour après pouvoir donner des droits d'accès assez facilement : tel utilisateur peut lancer tel action de tel controller ou non

Revenons un peu à la génèse de ce forum. Alors comme ça le modèle MVC serait la 8ème merveille du monde ? Il faut bémoler un peu quand même.
Tout d'abord, près d'un an après l'ouverture de ce forum, l'affaire n'a pas l'air si facile que ça.
Pourquoi ? Parce qu'il me semble que vous privilégiez le concept au détriment de l'objectif, parce que vous semblez considérer que ce concept est une fin et non pas un moyen et, désolé, parce que vous êtes le nez dans le guidon et que vous n'avez pas pris le temps d'une démarche conceptuelle globale avec le niveau d'abstraction suffisant.  
ouh la la ! ça fait mal d'entrée de jeu dans ce forum ! Enfin bon, il me semble.
A la lecture de ce forum, je m'aperçois que pour beaucoup d'entre vous la démarche MVC n'est pas intuitive. Le concept MVC de séparation des couches n'a pas pour but principal l'esthétisme de la programmation. L'objectif doit demeurer l'optimisation du développement, notamment en terme de délai, de productivité, de maintenance et d'évolution.  
Mon avis est celui-ci : le MVC devrait être transformé en MMVC (Métier, Modèle, Vue, Contrôleur) où seul le Métier devrait être codé, les autres devant être générés à partir d'outils wysiwyg (Vue), de modèles conceptuels (Modèle), de modèles cinématiques (Controller), Vue et Modèle devant également être mis en relation via un outil wysiwyg afin d'automatiser l'affichage. Ce qui manque donc, ce sont les outils en amont pour produire le MVC.
Alors là, oui, cela serait le monde idéal.
Pour finir (pour l'instant), je n'ai pas beaucoup entendu parler de modèlisation, de transformation de modèles, de génération de code dans ce forum. Et pourtant, je pense que ce sont les clés du succès de MVC.
Alors je vais surement me faire beaucoup d'ennemis dans ce forum et je m'attends bien entendu à vos critiques. Je voulais simplement ouvrir des perspectives.
 
------------
Mais moi les dingues j'les soigne, j'm'en vais lui faire une ordonnance, et une sévère, j'vais lui montrer qui c'est Raoul.

drapal!

ça s'annonce agité

tout nouveau sur ce sujet, je plussoie. Pour moi la génération de code est vraiment la route qu'il faut emprunter pour gagner en productivité et en qualité.
Le modèle MVC permet de bien séparer les taches : des ergnomes pour la vue, des hackers pour la partie métier et des architectes pour la modélisation.Et c'est tout son interet, car il est directement lié au cout de développement en temps et en ressourches humaines.

Oui, il faut effectivement bémoler
 
Loin de moi de faire passer le MVC comme la solution ultime. En fait pour
l'histoire, c'est une architecture à laquelle je suis venu presque naturellement :
 
J'avais une appli à faire en .net. Un machin un peu standard, avec base de données, formulaires, etc. J'étais dans le style débutant, avec juste les connaissances de base pour développer. Je ne m'étais pas encore trop intéressé aux différentes Design Pattern. Lors du développement, je faisais évidemment un peu n'importe quoi, du genre les requêtes SQL dans les évènements du formulaire, rien de séparé, un beau mix bien caca.
 
Alors voyant que je partais dans le mur plein phares en klaxonnant, j'ai décidé de tout refactoriser (tout recommencer). Là j'ai séparer toutes mes requêtes d'un côté (le model), et d'y mettre des évènement lorsque les données changent afin que le formulaire se mette à jour.
 
Plus tard, en lisant différents papier, j'ai appris que j'avait réussi à faire un machin qui ressemblait à un MVC *joie*. Plus tard, pour un développement en PHP, il me semblait normal de reprendre un peu les idées trouvables là-dedans, en les adaptant.
 
 

Ouhh yeah. C'est sûr, j'ai vraiment découvert MVC il y a un an donc (un peu avant l'ouverture de ce topic). L'objectif était de présenter un peu le concept de MVC, mais surtout de discuter un peu des architectures d'application possibles.
 
 

C'est normal : on est encore en train de discuter sur le concept même. Chacun expose ses vues et ses expériences. On a vu au fil des pages que MVC peut être implenté de différentes manières. C'est pour ça aussi que MVC est plus un concept qu'une design pattern.
 

Ouais, c'est exactement mon cas en ce moment. Je suis en train de développer un framework, alors je manque un peu de recul sur certaines choses. Je suis aussi tout seul à développer, donc je n'ai pas forcément quelqu'un qui peut me dire si ce que je fais est du total n'importe quoi ou non. D'où aussi ce topic, où j'expose parfois mes implémentations et idées, histoire d'en discuter.
 
Là encore, j'ai refactoriser 2-3 trucs, parce que c'était pas bien. Je commence à me dégager un peu du concept pour me tourner vers l'objectif : c'est une phase de transition. Il est clair qu'il me manque de l'expérience au niveau "architecture d'application", entre moi il y a 6 mois et moi maintenant, il y a un beau fossé.
 
 

Ca vient sûrement du langage utilisé. Historiquement et traditionnellement, PHP est un langage procédural. Plus qu'un langage, c'est un grosse bibliothèque de fonctions. A différencier donc d'un framework : on peut partir dans tout les sens.
 
A la base, moi comme beaucoup d'autres ont programmé de manière totalement empirique, à tout mixer ensemble : accès aux données, contrôle, et affichage. J'me rappelle de mes premiers scripts, c'était un merdier total. Et j'ai continué comme ça pendant assez longtemps, jusqu'au jour où il a fallu modifier et reprendre des choses. Et lorsque tu te surprends à devoir copier-coller des scripts juste pour changer un pauvre champ, bah tu te dis "peut-être que je fais fausse-route, et qu'il y a un meilleur moyen de développer".
 
Il faut donc passer d'un mix procédurale à une architecture définie orientée-objet. Heureusement que j'avais fait du Java avant, sinon bonjour le bordel.
 
 

Là faut définir ce qu'est l'esthétisme. Pour moi, un truc bien séparé est parfaitement esthétique.
 

D'où le MVC à la base. Essayer de découpler les choses et introduire une certaine abstraction. Aussi automatiser certaines choses.
 
 

Ouaip ouaip. J'y ait déjà réfléchi. On peut aussi introduire des modèles abstrait, où on fournirai un implémentation concrète : Genre un modèle "Table" où l'implémentation fournirai juste la liste des champs de la table, les différentes opérations étant fournies.
 

Ce sera prévu dans mon framework. Pour l'instant, c'est un peu d'HTML avec du PHP, donc rien de bien ultra-complexe pour un développeur standard
 

Là ça pourrait être un peu plus compliqué, y'a parfois certaines logiques à développer un peu complexe.
 

Je pense qu'il faut toujours faire un peu de code. Lorsqu'on automatique tout à 100% et qu'on fourni des outils wysiwyg, il y a toujours des cas qui seront relous voir impossibles à faire...
 

Oh oui
 

Tout ça viendra. En fait t'es arrivé au mauvais moment codegen, scaffolding tout ça devrait être implémenté, mais pas tout de suite.
 
 

Au contraire, merci pour ton intervention. Faut pas hésiter à continuer les débats pour arriver à l'architecture ultime

De mon point de vue, il ne faut pas prendre ce topic comme étant un guide "Comment développer rapidement une application web en MVC" car si c'était ça, je pense qu'il y aurait plutot des conseils sur  l'utilisation de tel ou tel framework.
 
Ce topic permet de présenter et d'expliquer ce qu'est le MVC, et en propose des fragments d'implémentation possible afin que chacun puisse comprendre le fonctionnement de ceci, et de pouvoir développer à sa guise un framework perso.
 
C'est du moins la manière dont moi je vois ce topic, et c'est l'objectif que je compte atteindre lorsque je m'atellerai au développement de mon futur "site" (qui n'aura d'autre but que de me faire bosser sur php).

 
NON, Non, non!!!
 
PHP qui génère du JavaScript qui génère du HTML c'est déjà suffisamment complexe.
 
À chaque fois que j'ai généré du code qui génère du code, non seulement j'avais l'impression que moi seul pourrait me relire, mais même moi je ne peut plus me relire (comme quoi si vous n'avez pas compris cette phrase sans la relire... ).

Je rejoins FlorentG sur sa réponse, effectivement ce post est plus un brouillon de découverte du MVC qu'autre chose, mais faut bien commencer un jour. Et rien que le fait d'avoir la volonté de suivre ce genre d'architecture rend le code meilleur je trouve, même si évidemment, y a moyen de faire bien mieux. Enfin tu as tout à fait raison, finalement nous nous intéressons plus au concept qu'à des applications professionnelles sur ce post.
 
Par contre là où je ne suis pas d'accord, c'est sur la deuxième partier de ton message.

Ce que tu proposes, c'est assez proche de certains framework .net. Et franchement, ça produit un code bien à chier. Je pense notamment à un framework payant proposant des modèles cinématiques, le consultant .net de la boîte s'en servait au final jamais et passait son temps à aller corriger le merdier de code obtenu en l'utilisant. Mais ça permettait aux débutants de produire un truc carrément plus correct que ce qu'ils auraient codé de leurs mains, ça je te l'accorde. Néanmoins, si les boîtes arrêtaient de faire bosser des stagiaires, y aurait pas ce genre de problème.
Et le wysiwyg, alors là laisse moi te dire tout le mal que je pense de ces méthodes pour concevoir les vues d'une application. Tu te retrouves avec un code incompréhensible, top pas optimisé, impossible à débugger. (et je ne relancerai pas un débat sur les moteurs de template ici, notamment celui "intégré" à .net, pour dire tout le mal que j'en pense )
 
Dans l'absolu, tu as raison, seul le métier devrait réellement être codé. Mais c'est bien connu, les informaticiens essayent de produire à chaque application un nouveau processeur en partant de silicium, au lieu de partir de composants électroniques existants
Mais y a une raison à ça : les composants existants ne sont pas encore à la hauteur, ou en tout cas, répondant difficilement à des besoins particuliers.