Reprise du message précédent :
Oui, je me suis bien rendu compte que c'était n'importe quoi    Mais comme j'arrivais pas à appliquer MVC, j'avais fais un truc à ma sauce. Mais un jour, je serais un homme comme vous, et ce jour là, MVC ne me fera plus peur    
 
Est-ce que les frameworks sont une bonne solution pour l'apprentissage de MVC ? J'avais des vues sur CakePhp qui semblait pas mal, enfin je dis ça mais j'ai aucune expérience niveau framework

Oui les frameworks sont bien pour prendre des bonnes habitudes et avoir un exemple de (a priori) bonne organisation sous les yeux.
 
En frameworks PHP je connais que les grosses machines (ZF, Symfony) mais dans le genre modeste CodeIgniter ou CakePhp sont pas trop mal il parait j'crois.

Dans le MVC, le vue et le controlleur peuvent communiquer avec le modele. Cependant en pratique, les implémentations ne le permette pas toujours car c'est moins clair. Mais d'un point de vue conception ce n'est pas une erreur.
L'inverse n'est pas permis par contre, jamais le modèle doit utiliser une vue ou un contrôleur de lui même.

Je connais pas bien la théorie, mais la vue peut utiliser le modèle pour consultation mais pas pour modification, c'est pas ça le truc ?
 
Enfin ça me parait logique surtout. Genre avec un ORM, on est quasi obligé d'utiliser les objets (modèle) dans la vue pour les consulter et les afficher.

Voilà.
 
Ca permet d'éviter le truc inutile genre BibliothequeController::getListeLivre(); qui fait un simple appel à Bibliotheque::getListeLivre();

 
Pas forcement, si tu t'interdit le lien Vue -> Modèle, tu t'en sort aussi, sauf que t'as ton contrôleur qui récupère toutes les donnée et les passes dans la vue (en général via des variables).

Voilà, ou simplement $livre->getNbPages().

Bah non, si il te passe un tableau de livres, t'auras quand même accès aux livres en eux-mêmes (modèle), sauf à les envoyer en tableau associatif ou une copie des objets...

 
Codeignoter est génial pour débuter, seule la partie modèle est un peu zarb (quoique j'ai pas testé l'ORM) je trouve mais j'ai pas trop de points de comparaison avec les autres frameworks PHP (je fais juste du rails à côté qui est beaucoup plus sympa avec ActiveRecord)

Le rôle du contrôleur en théorie c'est uniquement de traduire les demandes de la vue au modèle, puis de répondre OK à la vue quand le modèle lui a dit que c'était fait.
Derrière la vue se débrouille pour rafraichir ses données.

Je suis bien d'accord
 
(et même avec une webapp, si elle tape dans des webservices ton modèle sera ws-backed)

hum hum non, dans le MVC la vue et le modèle ne peuvent communiquer qu'avec le controller, si tu peux faire communiquer directement vue et modèle t'es dans un 3-tiers
 
Après notes que le controller peut filer des objets du modèle aux vues, c'est juste que la vue est pas au courant que c'est un objet du modèle

C'est du MVC ça

Ta vue elle voit juste des livres à afficher, elle sait pas ce qu'il y a derrière et elle s'en fout

 
Ca se discute, pour moi les deux implé se tiennent - on peut d'ailleurs lire le contraire ici ou là (voir wiki par exemple).
Le fait que la vue interroge directement le modèle ne remet pas en cause l'indépendance des couches - seule l'interface publique du modèle ne peut pas changer, et c'est déjà le cas si on passe par le contrôleur.

 
Tu peut très bien appliquer le MVC et le n-Tiers independement. i.e. avoir le serveur d'appli. et les couches présentation en MVC.
 
Point de vue MVC, le M du client reste qu'une classe de Proxy de WS vers le serveur d'application. Et du point de vu du serveur d'appli. le V c'est la sortie en Web Service.
Les deux appliques les principes du MVC tout en ayant une architecture n-Tiers.
 
Et tu peut donc avoir même qu'un seul maillon en MVC.
 

 
T'es libre de faire ton model à ta sauce dans CI, je ne vois pas ce que tu lui reproches.

 
Marrant, c'est le truc que j'ai utilisé dans mon soft Icare (cf signature). Le principe repose sur une sorte d'automate à états, qui suivant l'état, appelle une action et une vue. Par contre, le code source que file l'auteur est pas mal bugué et j'ai dû refaire pas mal de choses, mais j'ai gardé le principe...

J'ai téléchargé ton appli pour étudier ton code  

Merci. Pour info, c'est un soft de gestion de configurations.
 
Par contre, je pense que tu pourras trouver largement mieux pour ce qui est de l'implémentation d'un MVC. Pour ça, je te recommande le logiciel Magento (outil de boutique en ligne) qui repose que le Zend framework

 
Bah je reproche pas, c'est juste que  
 

 
ca fait un peu zarb je trouve

                   
 
Non.

Pourquoi, t'aimes pas Magento? L'architecture est certes assez complexe mais respecte bien le MVC.

C'est p'tet Zend Framework qui passe mal. C'est quand même bien lourd comme framework, alors si en plus on debut en MVC...

Bon j'ai regardé Magento et en fait non c'est juste que c'est la pire implémentation de Zend Framework que j'ai vu... ça respecte quasi aucun standard du Framework...

Peut-être, mais de façon bloatée à mort, avec 2 couches de frameworks au-dessus du Zend Framework, un modèle EAV hyper spécial entre autres... pas vraiment pédagogique disons

Pour étudier un MVC assez "complet", je regarderais plus vers Symfony (qui est full-stack) ou un truc simplement basé sur ZF sans en rajouter des tonnes.

J'ai fait 2 sites avec ça... à customiser, à comprendre, à optimiser, un enfer.

Je reste sympa parce que je connaissais mal ZF et les schémas MVC classiques, donc je me dit que c'est peut-être moi le pb... mais je ne pense pas

Le coup de la définition des blocs de données avec leur positionnement via des fichiers de confs en XML + les templates .phtml, c'est quand même assez fort et personnalisable, même si c'est vrai qu'au début, c'est chaud à comprendre. En plus, on peut appeler ensuite ces blocs via l'ihm du  backoffice et les utiliser dans les pages du CMS ou dans les fiches produits.

D'un côté les PHTML ca fait partie de la philosophie Zend Framework.

Disons que quand t'es arrivé à comprendre ce système de XMLs (j'ai bossé des mois dessus, je suis pas sûr d'avoir encore vraiment compris), t'as pas vraiment besoin d'une admin pour faire de nouvelles pages. Customiser une page produit particulière peut-être... jamais eu ce cas.

J'ai même pas vraiment compris à quoi ça sert de devoir déclarer des blocs dans les XMLs au lieu de les inclure simplement dans la page. Et un simple système de pseudo-chemins pour les cibler, et une syntaxe simple pour le back-office.

Ruby on Rails est sympa pour comprendre le MVC et l'utiliser à plein pot, mais le topic indique php, alors je suis peut-être hors-sujet?

http://forum.hardware.fr/hfr/Progr [...] 2151_1.htm

[HS] Je me permet un léger hors sujet. J'ai parlé avec les développeurs de ma classe, et pour l'instant aucun deux ne sait ce qu'est MVC (ils font principalement du java et un peu de php) alors que les cours se terminent dans à peine 2 mois. J'ai peine à croire qu'on puisse trouver du boulot dans le dev sans connaître MVC, pour ce qui est de bosser avec des framework, j'en parle même pas    
[/HS]

Ha ok, désolé, j'avais pas vu que ce topic était dans la sous-catégorie PHP.
 
Mais alors il n'y a pas de topic MVC "en général" non lié à un langage?

C'est les faibles qui prennent des cours

Et ceux qui accessoirement veulent un diplôme  
 
Edit: J'ai trouvé 2 tutos sur le site du zéro à propos de MVC, vous en pensez quoi objectivement ?    
 

• Le premier
• Le second

Quoi comme études ?
 
i.e. en sortie de DUT et LPro je crois que quasi personne de ma promo connaissait le MVC. Le n-Tiers déjà ptet seulement les 3/4 connaissaient...

BTS Informatique de Gestion. Mais ça doit pas être évident de commencer un premier job sans expérience avec MVC ou framework  

Il vaut mieux utiliser un vrai framework avec tout de prêt. Je trouve leurs exemples très durs à lire surtout avec des noms de fichiers news.php redondants.

Zend fait pareil.
Ils encouragent l'utilisation d'un autoloader qui donne à tes fichiers un nom différent de NomDeLaClasse.php

Ha bah tiens on en revient à Magento. J'avais souvent une douzaine d'onglets ouverts "Abstract.php"

Quand tu commences a avoir plus de classes abstraites que de classes concrètes ça devient bizarre.

Bof, t'as souvent envie de regarder ce que fait le framework...et là, c'est le drame.

J'vais voir du côté de CakePhp pour voir comment c'est foutu, pis leur site à l'air bien clair et y a pas mal d'explications