Reprise du message précédent :
vi ça semble fort prometteur, mais assez inutile actuellement non ?

Ouais Enfin y'a des fonctions intéressantes (style les fonctions de recherche, ou genre les machins RSS et webservices)... Maintenant on attend un vrai MVC... Là y'a vaguement l'implémentation de Views... Stay tunned

ha j'ai pas trop fait gaffe, tu nous fait un résumé de leur implémentation de la View pour les feignasses comme moi ? (un RTFM m'ira aussi)

RTFM

haaaaaan !!! (ok )

Bonjour, j'ai bien lu le tout et quelques "points noirs" me restent ...
Admetons la situation suivante :  
Une page affiche le login et l'id des utilisateurs d'un service, en cliquant sur l'utilisateur, on recoit sa fiche technique (nom, prenom, adresse,..) et on peut faire des actions diverses (des modifications et les enregistrer, supprimer, ou tout simplement retourner a la page d'avant) donc voila ce que j'ai compris :
Appel de l'utilisateur :  
Le controleur voit que l'utilisateur veut visionner la liste , il appelle une metode metier qui les recupere et les lui fourni (array d'objets, array tout simple ou autre), et ensuite il appelle une metode de la view , en lui passant la liste des utilisateurs comme parametre, et cette metode les mets en page et les affiche. Quand on clique sur le nom , c'est pareil (controleur appelle le modele, et envoie le tout a la vue) et ainsi de suite?
Ce qui me "perturbe" un peu ,c'est que dans le deuxieme lien que propose Florent , il y a ecrit :  
In MVC, The controller is NOT a Mediator between the view and the model.
Hors dans mon exemple c'est un peu ce qu'il fait non? A quel moment j'ai mal compris?
 Et question supplémentaire, admetons que d'apres le statut de la personne qui visionne, certains elements ne doivent pas etre accessible (par exemple l'edition et la suppression), c'est qui qui s'en occupe?. Si c'est la vue, elle devra faire des controles "bas niveau" (l'utilisateur est-t-il autorisé a faire ça?) , si c'est le controleur , je devrai donc avoir une methode de vue par type d'autorisation ?  
 
Merci d'avance

pti up

Je suis daccord avec cette approche qui consiste à séparer les éléments.
Personnellement je travaille le plus possible en objet c'est pour cela que mes projets sont divisé en 4 zone.
- Classe d'affichage
- Classe metier
- Classe extraction ou écriture des données (db, xml, fichier)
- Classe opérations (ex: fait la liaison entre la partie metier et l'affichage)
Je me donne un protocole qui dit que chaque classe n'a pas à savoir d'ou provienne son information quand elle la demande, tant qu'elle l'a. En gros si dans ma class "utilisateur" il y a un methode getGroupe, la classe utilisateur n'a pas à savoir que ça été cherché dans une db ou xml tant que getGroupe lui retourne l'objet groupe lui étant associé. C'est pareille pour les classes d'affichages. Ainsi je fais en sorte que l'application puisse rester ouvert, switchable entre les sources d'informations et réutilisable au mieux.
 
Pour en revenir au sujet, c'est extrement important de bien séparer sont code. Car lorsqu'il y a une modification c'est le début de la galère surtout si vous êtes à plusieurs.

Perso j'ai subdiviser mes classes Utilisateur , Produit ,... En 3 : business, persistance et presentation.  
Quand l'utilisateur demande qqch (une page par exemple), le business demande a la persistance de recuperer les differents elements (ouvrir les fichiers de config et les lire, faire des operations sur la base,...) , et cette derniere renvoie les info necessaires. A ce point le business fait les operations necessaires pour que le tout soit consistant, et apres il appelle la presentation qui affiche le tout a l'utilisateur.
Et pour jouer les maitres d'orchestre j'ai un controleur qui dirige les flux vers le bon module (Il regarde dans l'url a qui est destiné le flux)
Qu'en pensez vous?

Comme tu peux le constater quelques messages plus haut, j'ai soulevé le même détail. Ayant un peu réfléchi depuis, j'en viens à me dire qu'on a un peu mal interprété cette phrase.  
 
Je pense qu'ils veulent dire que le Controller ne passe pas chacun des paramètres dont elle a besoin à la View, mais qu'il lui passe simplement l'objet Model dont elle a besoin, et qu'elle se débrouille avec. Parce que bon, la View quoiqu'il arrive, y a un moment où faudra bien lui passer un truc. En ce sens, je trouve que quoiqu'il arrive, le controller est un médiateur pour la vue (avis perso). J'ai d'ailleurs depuis trouvé un ou deux articles disant que le controller devait être un médiateur pour la vue, alors bon    
 
Toujours quelques posts plus haut, on discutait du problème de passer des variables en session pour les transmettre page suivante à la view (genre traitement de formulaire et affichage du résultat du traitement). On se disait qu'on était bien obligé de faire du controller un médiateur.
 
En fait non : on met l'objet intéressant du Model en session (serialize), et on le refourgue à la vue page suivante (unserialize). On respecte bien le principe de filer directement à la View l'objet du Model.
 
 
Enfin voilà, conclusion pour moi, un controller est bien un médiateur, mais ça doit juste être une question de défintion.

Ca me conforte dans mes idées effectivement ... Mais la phrase d'apres dans l'article dit bien que le controleur et la vue doivent avoir le meme acces au modele ... Ce qui est un peu "contre" le principe du mediateur je trouve ... Enfin bon voila ...

bah, avoir le même accès au modèle, ça me parait difficile quand même. A moins d'avoir une méthode statique pour récupérer l'objet du modèle, ce qui serait crétin, c'est bien le controller qui instancie l'objet du modèle et lance l'action dessus. A partir de là faudra bien le transmettre à la vue.
Encore une fois, je pense qu'ils veulent dire que la view connait l'objet du modèle qu'elle utilise, et utilise ses méthodes.
 
Mais bon effectivement pour moi aussi ce point est assez énigmatique.

c'est de la théorie...dans le cas du php effectivement c'est pas trop faisable dans la pratique, ce genre de choses.

Je reviens a la charge avec une petite question qui me trotte dans la tete depuis un moment .
Chez moi actuellement le controleur transforme le flux sortant de la base de donnée en XML , apres avoir fait certaines modifications , ensuite il appelle la presentation qui ne fait enfait que lier ça avec le bon template XSLT.  
Ma , ou plutot mes questions sont : Est-ce bien le role du controleur de mettre en page le XML ? Et ensuite, quelle partie du boulot donner a la vue et quelle partie faire dans le XSLT? Parceque actuellement je fais certains controles (genre : Si aucun element est present dans un tableau, j'affiche un message) dans le XSLT et je me demande si ce ne serait pas mieux de les faire dans la vue

non c'est clairement pas son rôle. Le rôle du controleur serait plutôt d'appeler la fonction générant le XML, plutôt que de le générer lui même.
 
Du XML, c'est une sortie, ça va dans la vue. ET le XML, ET le XSLT font partie de la vue pour moi. (tu pourrais très bien généré du html sans passer par XML, et là tu n'aurais pas de doute sur le fait que c'est une sortie).
Donc le contrôle genre si aucun élément n'est présent, afficher tel message, ça va dans la vue, que ce soit fait en XML ou XSLT. D'ailleurs ça étoffe mon opinion que le XML c'est purement de la vue : affichage de résultat quoi.
 
Bref, dans ton cas ça devrait être d'après moi :
 
Controler -> instancie le Model
Model -> récupère les données dans la base
Controler -> instancie la vue (qui génère le flux XML)
Controler -> passe le Model à cette vue
Vue -> génère le XML et le XSLT à partir du Model
 
Finalement, come ça été dit dans les premières pages de ce post, le rôle du controler est bien sommaire : il instancie le model et la vue, c'est tout. A partir du moment ou tu fais des calculs, des gros traitements, tout ça , dans le controler, tu peux te dire qu'il y a surement un souci
Et y a pas mal de design patterns qui mélangent la vue et le controler, histoire d'insister sur le fait que le rôle du controler est bien léger

Mais dans ce cas, a part faire le "chef d'orchestre" , le controleur ne fait plus rien. Il ne fait que dire a la couche metier et a la persistance ce qu'elles doivent chercher, et a le donner par la suite a la vue ... Est-ce vraiment son role?

voir mon édition : oui

D'accord ... Je crois que donc je vais avoir une architecture a plusieurs controleurs .. L'un principale (celui aucun l'utilisateur aura un acces direct par url, appellant les autres selon la nature des arguments passés dans l'url & co. ) Merci bien en tout cas

Le controlleur ne devrait pas aussi vérifier les données passées par GET, POST, SESSION, COOKIES, les enregistrer aussi ?
 
 
Le flux XML dont vous parlez c'est un flux XML contenant les données servant pour le XSLT qui contient "le template du site" ?
Ne serait-ce pas plutôt au modèle de le générer  et la vue le récupère pour faire la transfo grace à XSLT en quelque chose d'autre ?

Dans votre archi, vous n'avez qu'une seule entrée dans l'url et que des paramètres après ? genre index.php?param1=...&param2= ????????

Non en tous cas pas le modele. Parcequ'il doit etre independant de ce qui vient apres. Hors s'il crée un flux XML et que la vue ne le gere pas, il faudra faire une etape supplémentaire , cad transformer le xml en autre chose

bah y a un truc que je trouve roxatif dans le controler, c'est : frontcontroller + objets command, qui rejoint ton désir d'avoir plusieurs controllers.
 
Absolument toutes les entrées passeront toutes par le frontcontroler. Ca permet de gerer les éléments communs à toutes les pages (genre instancier un objet User, afficher les en-têtes et pieds de page, etc).
D'autre part, Il instancie un objet command en fonction de la page demandée. Et c'est cet objet command qui prend la releve. Le frontcontroller reste clean.
 
En exemple, je te mets un petit bout de mon frontcontroller:
oups, jsuis sous windows, je reboot et jte le mets.

Pour les entrées utilisateurs, sisi c'et bien son rôle de les récupérer. Pour moi, le controller récupère les variables post, get, session, sketuveux, fais les controles de sécurité dessus (à base de settype), et les envoie au model.
 
Le model ne doit pas savoir d'où lui viennent ces données. Ce n'est pas à lui de les récupérer

Perso mon frontcontroler prend la forme de qqch qui prendra une url genre :
monFrontControler.php?module=administration&action=addUser
 
Il instanciera donc le module Administration, lui donnant comme ordre d'executer addUser. Maintenant la question est : Qui va chopper les info sur l'utilisateur dans le $_POST ? Probablement le modele non?
 
Ok Djebel .. Mais tu lui passe ça comment a ton modele? Tu lui passe tout le $_POST/$_GET/$_SESSION "securisé" ou tu tries? Parceque dans ce cas le controleur doit savoir de quoi a besoin le modele ... et c'est pas le but non?

> Parceque dans ce cas le controleur doit savoir de quoi a besoin le modele ... et c'est pas le but non?
 
Tu me mets presque le doute, mais je pense que c'est bien son rôle. Je pense que ce n'est pas le rôle du model de savoir d'où viennent les données. Que ça soit en get, en post, en cookies, il doit faire son taf, sans se préoccuper de ça.
 
En plus, Le controler et la vue sont tous deux dépendants du model : des modifications sur le model peuvent entrainer des modifications sur le controller et la vue, mais pas l'inverse.
Donc oui, ça me parait logique que le controller sache ce dont a besoin le model.

Sans dec vous me faite mal à la tête quand je vous vois chipoter sur des détails  
- Trouvez un stagiaire payé au ticket resto et dite lui "je m'en fou il faut que ça fonctionne"

Ca tiens la route, c'est d'ailleurs ce que je fais. Mais ça veut dire que donc le modele et la vue sont intependants, et que le controleur lui est donc "lié" autant a l'un qu'a l'autre ...

demande au stagiaire !

Le problème c'est que moi je fais ça par pur plaisir . J'apprend juste parceque ça me semble important que ça soit bien fait . Donc j'ai pas trop de stagiaire sous la main

la vue est pas du tout indépendante du modèle. Puisque elle le connait et sait comment récupérer les informations. Le modèle est indépendant de la vue et du controleur, pas l'inverse.
Une modifi du modèle peut entrainer une modif du controleur ET de la vue

   
D'la bombe! enfin en phpV il est possible de faire ceci
 

mais retourne raper toi

j'aime pas le rap mais je break dance  

C'est ce que j'essaye d'éviter
 
Je pense que seule la View doit savoir vraiment quelle gueule a le model. Le controller, ne doit savoir que le minimum. Il doit juste pouvoir exécuter 2-3 méthodes sur le model (genre add, update, delete, validate), et instancier la bonne vue.
 
Si je change le model (genre je rajoute un champs), il faudrait n'avoir à changer que la view. C'est pas super compliqué. Exemple :

 
Donc on a une fonction qui retourne un tableau contenant la liste des champs, avec pour chaque champ la possibilité d'y mettre la valeur et un message d'erreur. La fonction validate valide ce même tableau après que des données y soit ajoutée, et la fonction add ajoute un enregistrement dans la base.
 
Ensuite, le contrôleur ressemble à ça :

TADA §§§ Si je change un champs dans le model, pas besoin du tout du tout de changer le controller. Le seul truc à changer, c'est la view, par exemple le formulaire de saisie qui devra refléter les changements Aussi, si les données doivent provenir d'ailleurs que $_POST, suffit de changer le controller, pas super compliqué...

ça a l'air pas mal ton histoire. J'ai juste un peu peur que ça ne soit pas assez générique. Tu as bcp eu l'occasion de tester ? Tu n'es pas tombé dans des cas où ça ne collait pas ?
 
En plus avec ta méthode, limite tu as besoin que d'un seul controlleur : il instancie la bonne classe du Model, et le reste est toujours pareil au final. Malgré tout, dans l'absolu, il n'y a pas de contre indications au MVC d'avoir un controller qui dépend du Model, il est bon de le souligner ^^
 
Par contre tu fais quoi en vrai avec $data['id']['error'] ? (vu que tu ne t'en sers pas là)

je profite du up de ce topic pour poser une question restée sans réponse jusque là.
Quelqu'un a-t-il déjà essayé le framework cakePHP?

oueche   c'est quoi ce site qui mene sur "le monde" ?

ok j'ai corrigé le lien j'avais un peu merdé ( par contre moi ça allait par sur le monde )

Je sais pas, c'est en cours de développement, je verrais bien si y'a un truc qui foire ou pas
 

Voilà, rien ne t'emplêche d'avoir un controlleur réutilisable. C'est l'objectif même du MVC, avoir des composants réutilisables
 

Genre si les données proviennent d'un formulaire, c'est lors du réaffichage du formulaire, ça affiche les messages d'erreur. Comme ça, le model gère lui même la validation. Si jamais un truc change (genre un champs qui devient obligatoire au lieu de facultatif), on modifie juste le model.
 
 

Ouais, j'ai vu ça. Et je pense que c'est pas mal. C'est un framework plutôt "lightweight", donc assez libre de faire ce que tu veux. Ca file juste la structure de base pour coder. C'est un peu ce que je fais en fait. Je pense pas qu'il faille faire un truc trop lourdingue qui te fasses tout et qui au final fait tout ramer, comme certains frameworks qu'on peut trouver...

tu fais chier, jvais devoir modifier mes controllers avec ton truc :x

Tu vois il faut pas écouter les autres