Reprise du message précédent :
C'est un peu le problème que j'ai vu dans la plupart des couches d'abstration DB - dès que que le mapping DB/classes n'est pas direct c'est le merdier...
Si c'est un "nouveau projet" et que ton ORM te permet de générer la base de données pas de gros problèmes, tu décris ton truc à fond via la syntaxe de l'ORM et basta, mais si tu pars d'une base existante tu te retrouves à devoir re-décrire explicitement un paquet de trucs pour que ta couche d'abstraction ne fasse pas de la merde...

Oui, mais je ne défendais pas Doctrine spécifiquement quand je parlais de vitesse de codage, plus des ORMs en général (en l'occurence, Doctrine VS pas d'ORM).
 
Sinon c'est "Retrieve", pas remove    
 

Ouais, enfin ça reste des cas spécifiques quoi.

L'héritage un cas spécifique
 
Sérieusement, l'héritage c'est ultra courant en POO... Je sais pas, c'est la base...

lulz. C'est pas parce-que tu bosses sur des projets au modèle simpliste que c'est le cas général.

Oui enfin c'est pas parce-que t'as de l'héritage dans les classes de ton modèle que ça veut dire que c'est compliqué à mettre en place systématiquement non plus hein.

Ton problème ne se passe que dans 1 mode d'héritage de Doctrine sur 3...
 
J'ai construit une grosse centaine de modèles avec Doctrine et j'ai jamais eu besoin de concrete inheritance... Je dis pas que ce soit jamais utile bien sûr, mais oui ça reste un cas spécifique.

Dans 2 semaines je vais travailler en entreprise sur cakephp, là je suis en train de découvrir le système des MVC, je galère pas mal...

Je comprends pas ta remarque, pourquoi c'est gênant par exemple que le nom des controllers corresponde au nom des tables (les deux au pluriel) et corresponde au nom du model, qui est au singulier.

J'en avais déduis que (attention, grosse simplification), model=objet ou instance et controller=class d'où le pluriel vu que ça comporte plusieurs objets, contenus dans la table correspondante, c'est erroné?

(je viens juste de finir le tutoriel du blog )

Parce qu'une méthode donnée d'un controller peut parfaitement impliquer plus d'un modèle, la relation entre les controller et les modèles est n-n, pas 1-1.

Complètement

 
Ah ok je vois, oui vu comme ça ça peut paraître bizar/
 

 
Arf
 
Je précise que quand j'écris model=objet... c'est pas exactement ce que je veux dire, mais plutôt que un model travaille avec 1 objet de la table à la fois, d'où le singulier, alors que le controller gère tous les objets, d'où le pluriel... c'est encore erroné?

En Zend Framework, y'a pas de convention particulière sur le nom du controlleur...
 
Souvent j'utilise le singulier perso.

Oui. Si tu fais quoique ce soit avec la BDD, ça doit être dans la couche modèle.
 
La couche controller, ça n'a rien à voir avec la BDD (elle ne doit même pas connaitre son existence).

Disons que c'est plus logique d'avoir un nom de base "Bicycle" et d'appeller sa collection BicycleCollection, plutôt qu'un nom de base Bicycles qui corresponde à une collection et d'appeler l'objet BicyclesObject...

 
ok ! ça fait sens, donc la convention qui veut que le nom d'un controller corresponde au nom d'une table (sans quoi ce n'est pas d'un controller mais d'un component dont on a besoin dixit cakephp), ça a juste à voir avec le fonctionnement interne de cakephp, ya pas de signification particulière à y voir coté utilisateur.
 
 

Non. Par ex dans symfony ya pas de ça, c'est toi qui crée tes action controllers et les organise comme tu veux.
 
Après forcément ya une sorte de logique à calquer les controllers sur la couche modèle, mais c'est pas obligé.

Non.

 
Je suis à coté de la plaque je crois    Je vais faire des tutoriels, bidouiller, et moins théoriser, juste accepter les conventions comme elles sont, ça me réussira ptet mieux.  

 
ok

 
On est pas obligé de suivre cette convention tout pourrie de cake, j'imagine qu'ils font ca pour faire "RESTful"

J'ai un controlleur "news". J'aimerai pouvoir lister toutes les news pour les visiteurs, mais aussi pour les admins avec des options différentes.
 
Je suis sensé faire quoi, une seule méthode avec des if dans tous les sens, deux méthodes différentes ou alors j'ai une classe pour tout ce qui est admin de news et une autre pour le reste ?
 
Pour l'instant je suis partie sur l'option 2.

Option 1 amha (enfin çà dépend si ca te semble plus une page news + qql options pour admin, ou si c'est plus du tout le même objectif)

Au plus pratique.

Même contrôleur, sauf que dans le modèle soit tu te base sur le profil de session pour savoir si c'est en visiteur ou admin, soit tu fais du if else... sachant qu'en principe tu devrais avoir un truc du genre :

Ca c'est le raisonnement qui reviens a dire, faire du code de merde, ce n'est pas grave...

Du code de merde, c'est pas pratique.
Ce que je voulais dire c'est qu'il n'y a pas de "bonne pratique" admise pour ça, c'est selon.

Par ex ta solution est bien, sauf si la part d'éléments différents est plus grande que celle d'éléments communs, auquel il faut largement mieux factoriser dans l'autre sens (faire 2 pages séparées et factoriser dans des méthodes/templates les éléments communs).

Ça serait quoi les différences entre user et admin? Et elle s'exprimerait à combien d'endroits? Tes modèles sont goupillés comment, t'as un type différent pour les admins ou pas?

 
Les différences qui me viennent sans trop de réflexion :

• template différente
• données passées pas exactement les mêmes

Il y a uniquement deux pages pour lister les news, une pour les admins, une sur le front.
 
J'ai un modèle pour les news.
 
Juste un type User avec une propriete admin à true ou false.

Colles juste quelques conditions dans le controller et/ou template.

En pratique, le controlleur doit choisir la vue qui va bien, mais tout le reste c'est au modèle de se débrouiller.
Et encore que si la présentation est différente.
 
En gros dans le cas classique on devrais avoir un truc du genre dans le contrôleur, après pour le fetch, si l'admin vois pas les mêmes news qu'un visiteur (i.e. genre il vois des brouillons), c'est au modèle de gérer ça.

 
Et donc après, deux vues, une pour chaque cas, si vraiment c'est très différent en formatage.

Et tu te retrouves avec 200 lignes au lieu de 20 pour arriver au même résultat. Fuck everything about that, Rube Goldberg est mort depuis 40 ans.

Accessoirement tu devrais rajouter des indirections, c'est beau, utile et ça coûte rien.

Soit on fait du MVC et c'est pour une bonne raison (à priori des bonnes vu qu'on réfléchis à ça au début du projet), et on le fait proprement, soit on ne le fait pas.
 
En plus ma solution, ne dupliquerai aucun code métier, et donc ne demande pas plus de code qu'une solution moins "MVC" (bien au contraire). Seule la vue est dupliquée, et là encore, soit on a >50% du code qui est commun et on ne fait qu'une vue, soit on en fait deux pour être propre.
 
Et une 3e solution est toujours possible avec une vue principale qui fait des render de vue partielle en fonction du profil.
 
Exemple :  

 
Après je sais pas trop comme les données sont fetch et tout, mais le modèle pourrais très bien se résumé à ça :

 
Wahhouuuu, 15 lignes de code pour fetch, et franchement, a moins d'avoir un requête relativement complexe avec des jointure différentes suivant le type de profil, on ne devrait pas dépasser les 50 lignes pour ça, gestion des erreurs/logs compris.

ftfy.

 
oh oui bonne idée, allons mettre de la logique métier dans la vue.
 
Si ta liste de news est différente suivant le profil de ton utilisateur, c'est que le modèle a besoin de connaitre le type utilisateur pour t'en renvoyer la liste, point barre.

J'ai pas dit le contraire...
 
Mais après ça dépends la présentation de ta news suivant le contexte. Si t'as qu'un bouton "Edit" en plus, à priori tu ne va pas faire 2 vues différentes. Et ce n'est pas le modèle qui génère le HTML de sortie, donc de toutes façons c'est pas la dedans qu'on pourra gérer une présentation différente entre un visiteur et un administrateur.
 
C'était pour noter qu'on pouvais factoriser une partie de la vue.
 
Mais on aurai pu avoir deux vue différente avec un "render('news-commun.phtml')" si tu préfères.

C'est juste un peu la première règle en MVC le : " fat models, skinny controllers "...    
 
Après on peut avoir un contrôleur de 5000 lignes de code avec 500 lignes par actions à gros coup de conditions à tout bout de champs, mais là on ne fait plus du MVC...

désolé mais je n'ai pas tout lu ( 59 pages ca commence à faire )
actuellement je suis en train de développer mon "propre" MVC j'ai presque fini, mais je me pose encore une question:
pose du problème : certaine des actions commandées par le client font appel à d'autres informations provenant d'autre classe.
mais voila je ne sais pas comment faire ?
actuellement le client arrive sur l'application par l'adresse exemple : www.exemple.com/gestion_user_edit_1.html
mon contrôleur analyse l'URL et déduit qu'il faut appeler le MultiActionControler user et lancer la méthode edit sur l'id 1
La méthode edit sélectionne la vue puis le contrôleur reprend la main et lance la vue en lui passant les données.
si maintenant je veux faire afficher en plus de l'utilisateur ses droits, je doit dans ce cas utiliser le MultiActionControler droit mais je ne sais pas comment faire?
dois-je rappeler mon contrôleur pour lui faire charger les données ou le faire directement dans le MultiActionControler de la table user ou existe-t-il une autre méthode que j'ignore ?

Difficile de te répondre, là...je n'ai pas la moindre idée de ce que tu entends par "MultiActionControler" - encore moins quand il y a à la fois controler dans le nom, et que tu l'associes à une table.

j'ai créé ce que j'appel un MultiActionControler  
en faite c'est ce que FlorentG appel dans son premier poste class UserController
c'est une classe qui va s'occuper de traiter la demande de l'internaute
il pourrait ressembler à ça :

Si ton contrôleur doit permettre de visualiser/modifier les droits de ton utilisateur, je vois pas pourquoi il irait pas les chercher tout seul comme un grand.
Ta question me donne l'impression que dans ton esprit tu lies beaucoup trop ton contrôleur à ton modèle.

a bon, pourtant mon model est tout à fait indépendant du reste.
je suis partis du principe d'un CRUD sur chaque table pour le multiActionControler
et j'ai un model (accès à la base données) qui pour chaque multiActionControler et action établie un requete SQL.
 
Fonctionnement de mon contrôleur :
Le controleur ce charge d'analyser l'URL, de définir une route par défaut (si nécessaire) charger le bon multiActionControler, vérifier la présence de la méthode demander et si elle existe la lance (si elle n'est pas trouvé chargement de la méthode par défaut).
Le controleur instancie aussi une classe de retour appelé ModelAndView, qui contient les données en provenance du model (mais qui est initialisé par le multiActionControler) et la vue à charger qui a été initialisé par le multiActionControler.
La méthode render du controleur analyse la classe ModelAndView et génère la sortie.
 
voila pour le fonctionnement.