Reprise du message précédent :
non
mais la classe d'action construite par défaut est comme ça, et encore une fois, je trouve pratique d'avoir la partie authorisation bien visible

de toute façon, la gestion des droits est souvent problématique a placer dans le mvc, avec des bouts qui sont dans le controleur de d'autres dans la vue

ça dépend surtout de ta manière de structurer le truc, je pense.
J'ai tendance à vouloir toujours séparer au maximum les parties "admin" des parties "user", pour justement éviter de passer mon temps à vérifier des droits d'accès....mais après tout dépend de l'appli, dès que t'as des règles complexes tu peux difficilement faire autrement.

Donc en gros t'as un contrôleur public et un contrôleur admin par composant ?
 
Ce qu'il faudrait que je fasse c'est donc faire hériter tous mes contrôleurs d'un contrôleur générique ?

et donc tu duplique tes actions "afficher" "lister" , "rechercher" qui sont quasi  communes juste pour pouvoir séparer create/update/delete  ?
mouais, je ne suis pas fan

C'est un peu de l'extremisme, et en plus, dupliquer du code apporte d'autres problèmes  et du taf en plus

J'ai pas dit qu'il fallait que tu fasses ci ou ça...mais niveau maintenance c'est plus pratique si tu peux remonter le code commun dans une classe mère oui...

Si c'est quasi commun, ça doit pouvoir se factoriser dans une classe mère.
En fonction de l'utilisateur connecté tu linkes pas le même contrôleur "fils", c'est tout.
Si tu as la même action du même contrôleur pour chaque type d'utilisateur, tu te retrouves vite avec un gros paté de code pour gérer les différents cas, ça te donnes des actions imbuvables et qui ont toutes la même structure de contrôle du type utilisateur...je trouve ça super moche.

(dans le même genre, je supporte très mal les actions qui servent à la fois à afficher et à valider un même formulaire...mais bon j'ai conscience que c'est très perso, comme réaction... )

N'exagère pas non plus
le "gros paté" de code est en général quelque chose du genre

if($sf_user->gere($structure)) // on redirige les petits rigolos qui tentent une feinte a deux balles

Sur deux ou trois actions "sensibles"

A la place tu remplace un contrôleur par 3 ( le père, le fils admin, le fils non admin)

En bonus, je sers la même vue, qui au milieu contient  des bout de code du genre

if($sf_user->isAdmin()) // lel ien vers la modification

a la limite, ça peut se remonter dans le controleur, et la vue ne récupères que de flags  en fonctions des autorisations.

Je fais une névrose face à la duplication de code et l'encapsulation à outrance

if($sf_user->gere($structure)) // on redirige les petits rigolos qui tentent une feinte a deux balles

 
T'as vite fait d'en rajouter 3/4, des contrôles de ce genre, avec des droits d'accès un poil complexe...et si possible combinables avec des traitements résultants tous différents.
Si tu te retrouves au final avec des actions de 300 lignes, au-secours.

Si la gestion des droits est factorisable, tu as ( ou tu crée ) un helper pour ça . SI ça ne l'est pas, ce n'est pas la faut du contrôleur
 
Le pire que j'ai ici (appli de suivi de temps/paiement), c'est 6 lignes pour le contrôle des droits avec des fonctions de haut niveau  (qui font appel a une poly tetra chiée de fonctions, mais on s'en fout)  

Si tout ce que tu fais c'est vérifier qu'ils ont accès à la suite tout va bien.
Si derrière tu dois les traiter différemment, pour moi ce n'est plus la même action - ou la même action mais dans un autre contrôleur.

Après on rentre dans des détails d'implémentation assez dépendants des spécificités des frameworks les plus répandus, là...ne serait-ce que le concept d'action on n'est plus vraiment dans un MVC "générique".

Oui mais c'est ça qui est intéressant

Edit : étant donné que j'utilise CI et que mes contrôleurs étendent le celui de base, je me verrai bien utiliser un hook. Vous en pensez quoi ?

on parle bien de contrôle d'accès  et d'ajustement a faire dans la vue  
par contre effectivement, si derrière ce sont des vues complètement différents ou des actions différentes, alors bien sûr je sépare. Mais honnetement, ça arrive assez peu  
 
Les détails di'mplémentations font qu'une pratique est bonne ou mauvaise, bien au délà de l'idée de base.

C'est pas dans les actions en général. C'est géré par un filtre de sécurité qui va lire la conf dans les security.yml (où on définit les credentials nécessaires par module/action).

sauf erreur de ma part (mais j'ai un peu de mal avec les filters), ça permet de gérer les acces / pas acces à un module , mais pas des choses un peu plus subtile, si ?

coucou  
alors j'ai un peu avancé...
 
pour rappel mon probleme c'est de distinguer les traitements qui vont dans le controller de ceux qui vont dans le Model
par definition le controller ne doit contenir aucun traitement , mais apres , ca depend ce que l'on appelle traitement ...
 
j'ai tendance a me retrouver avec dans mon controller des alias de fonctions du model, je separe bien les couches mais je ne suis pas sur que ce soit la bonne methode . vous en pensez quoi ?  
 
concretement , imaginons un controller account qui est un controller fille lancé par le controller maitre de la page .
 
imaginons que je veuille aller sur la page listertous les utilisateurs.  
 
j'ai une fonction $controller-> listAllUsers()
 
dans le controller cette fonction effectue un alias vers la fonction account correspondante dans le modele.
concretement .  
dans le controlleraccount

dans le modelaccount
 

 
je ne trouve pas ce tres productif , donc il ya sans doute quelque chose que je n'ai pas compris .  
la vous pourriez me dire qu'il ne s'agit pas d'un traitement , ok . mais avec un vrai traitement ?  
exemple
controller:

dans le modelaccount
 

 
vous en pensez quoi ? je suppose que je rate quelque chose.  
 
d'autant que c'est aliasing me pose d'autres problemes : le modele a besoin d'acceder a la bdd , or c'est l'objet controller qui stocke l'objet PDO (ici en l'occurence)  
donc soit je fais un acces direct dans le modele mais je linke des couches que j'aimerai ne pas linker  
ou alors je fais ce que je vois dans bcp de tutos, cad que je stocke l'instance pdo dans le controller mais alors je dois le fournir a chaque fonction du model (tout du moins celles qui en ont besoin) et le passe en parametres, je ne vois pas vraiment l'interet.  
 
le plus logique serait de stocker l'objet pdo directement dans le modele mais je n'ai vu ca dans aucun tuto .  
 
bref , vous pensez que je suis completement a coté de la plaque ?  
 
merci bonne soirée.

 
Ce que perso je fait avec Zend Framework :
 
Modèle :

 
On peut voir que y'a que des setter/getter, la logique de persistance est inclus dans la classe mère et très générique.
 
Contrôleur :

 
Ici on vois que suivant le besoin j'utilise le modèle ou le dbtable.
Alors on va me dire qu'entre mes modèles très/trop proche de la couche persistance, et mes contrôleurs utilisant une couche pas assez abstraite pour accéder aux données, c'est pas gégé, mais au finale ça fonctionne, le code est clair et maintenable.
 
Y'a beaucoup mieux à faire j'en suis conscient, mais c'est déjà un début de piste. Mais le cas particulier c'est que j'ai implémenté ça en sachant qu'on utiliserais toujours Oracle comme SGBD, ce qui en fait a permis de simplifier au maximum la couche de persistance et de faire que l'on puisse géré la persistance d'un objet avec le moins de code possible.
 
Bien sur si on veut pouvoir switcher entre Doctrine et Zend Db par exemple, ça demande un mécanique plus complexe. Mais j'ai tendance à penser que l'abstraction pour la beauté du geste restait parfois bête si on est pas sur que ça serve.
 
NB : A noter pour ceux qui ne le serait pas, on peut utiliser une partie du Zend Framework sans utiliser toute le mécanique MVC. Ce qui fait que soyons fou on peut utiliser Zend_Db avec Symfony par exemple.

Dans ton modèle tu n'as donc que des objets qui héritent de Zend_Db*?
ça explique ton histoire de "couche service"...

...et tu utilises les dbtable directement dans le controller, wtf?

+1 Et v'la le nom, $dbTables... Faut nommer ça en $users par exemple, on n'a pas à savoir que c'est une table en base de données. Et c'est dans la template qu'il faut faire le fetchAll, le controller ne doit pas savoir quelles opérations sont faites par la view/template, il ne fait que refiler le bon modèle.

Et sinon quelqu'un connaît un équivalent à Sequel en PHP ?
 
C'est un ORM qui permet notamment des requêtes "avancées" du type :

 
Sans virer dans du raw sql.

Je n'utilise pas ce principe dans ce développement car tout simplement il est assez vieux et qu'à ce moment là j'avouerais qu'on est passé à côté de ça.
 
Après, tout les objets qui sont en BDD oui hérite de Zend_Db, ceux qui sont géré via des Web Services implémente une interface spécifique (pour la sérialisation/dé sérialisation), et le reste sont des classes ordinaires.
 
Le vrai soucis étant que si réellement on voulais séparer les objets de Zend_Db (ce qui est possible), on devrait alors faire pas mal de code supplémentaire, et quand on sait qu'il est hors de question qu'on utilise pas un SGBD pour ces objets, clairement faut se demander si c'est intéressant ou pas d'avoir une couche d'abstraction.
 
D'autant que malgré tout, utiliser Zend_Db nous assure de pouvoir changer de SGBD (passé de SQLite à Oracle n'a pas été un soucis par exemple).
Après si on est frilleux, sur le même principe tu remplaces :
- Zend_Db_Table_Abstract => My_Persistent_Mapper_Abstract
- Zend_Db_Table_Row_Abstract => My_Persistent_Object_Abstract
 
Et t'implémente ta couche d'abstraction à ce niveau là.
 

Bah on a deux autres choix possible :
- faire un mapper
- faire des méthodes statiques
 
On en reviens au point précédent, est-ce que ça vaut le coup d'écrire un mapper par objet persistant si on sais qu'on utilisera toujours un SGBD pour la persistance ?
(sachant qu'avec Zend_Db, on peut changer le nom d'une table ou d'un champs sans qu'on est à faire beaucoup de modifications)
 

$users pour moi c'est mes objets "User", donc pas le DbTable.
 
Après pour moi, c'est au contrôleur de récupérer les objets et de les envoyer à la vue, donc c'est bien à lui de faire les requêtes.
La vue n'a besoin que des objets de base sur lesquels elle travaille directement, i.e. ici les "User" afin de créer sa liste.

Dans Ruby l'avantage principale c'est le langage qui permet beaucoup de choses niveau syntaxe.
 
De ce que je sais Zend_Db fait +/- ça. Mais c'est plus verbeux.
Ca donnerais :

Non le contrôleur ne doit pas faire des requêtes, car il ne doit pas savoir comment la donnée est stockée, ça peut-être une db, un fichier, un webservice, ou tout ce que tu veux.
 
Le contrôleur va éventuellement faire des opérations sur les données avant de les données à la vue.

 
Oui en effet c'est pas très folichon

On peux être intégriste et jouer sur la forme plus que le fond, mais c'est bien le contrôleur qui se charge de récupérer les données dont la vue aura besoin.

 
Ton modèle est uniquement constitué de ton ORM, là. C'est très, très mauvais. Changer d'ORM est impossible, les tests unitaires ils peuvent se brosser, tu exposes probablement des gros bouts d'ORM à l'extérieur de ta couche Modèle...c'est mauvais, ya rien de plus à en dire.
Ta fonction qui retourne tous les utilisateurs, ça devrait être une fonction statique d'une classe "User" (Model_User dans les conventions zend...) de ton modèle, qui ne devrait en aucun cas hériter d'un Zend_Db*.
 
 

Ce n'est pas ce que dit MVC.
 
 
 

Non.

Sérieusement, MEI, tu confonds MVC en général et la manière dont personnellement tu utilises zend.
Ce que tu fais ce n'est pas du MVC, que tu le veuilles ou non, et vu les bouts de code que tu montres ce n'est même pas une bonne utilisation de zend, alors si tu pouvais éviter de raconter des conneries...

Houla, mais j'ai précisé directement que c'était pas 100% MVC compliant.
 
Pour le fetchAll/find on a pas fait de méthode statique tout simplement parce que PHP est trop bateaux pour faire que les méthodes statique des classes mère ai le contexte de le classe fille. (pas de static:: avant PHP 5.3 malheureusement).
 
Et bon, recopier du code dans chaque classe ce n'est pas la solution non plus niveau maintenance.
Là on s'écarte un peu du MVC, mais il n'y a pas de code dupliqué.
 
Sachant que des fetchAll() on en fait pas souvent non plus en pratique.
Le jour où on passe en PHP 5.3, 1 ou 2H de refactoring avec NetBeans et c'est réglé ceci dit.
 

Le MVC dit que :
- modèle assure la cohérence des données et sa persistance.
- le contrôleur réponds aux évènements de le vue et synchronise modèle et vue.
- vue affiche le modèle et gère les actions de l'utilisateur.
 
Du coup, si le contrôleur synchronise modèle et vue, ça passe aussi par récupérer le modèle et le lier à la vue.

 
Je ne vois pas trop comment faire autrement...
 

 
As-tu déjà utilisé Zend Framework ?
Parce que ton postulat est faux, il n'y de bonne façon d'utiliser Zend Framework (ce qui j'avoue est déroutant vu qu'on ne sais jamais qu'elle est la bonne pratique vu que chacun fait à sa sauce).
 
ZF c'est pas Symfony ou Ruby on Rails, ça n'impose rien du tout, ça ne fait que proposer une boite à outils.
 
Hormis la dérive au niveau de Zend_Db (encore que ça reste pour deux cas particulier), tout le reste est dans ce qui se fait couramment en Zend Framework, du QuickStart officiel aux livres publiés.

 
La vue affiche le modèle. Tu as tout dit. La vue demande directement au modèle les données dont elle a besoin.
Le contrôleur ne passe pas les données du modèle à la vue, il demande l'affichage de la bonne vue, c'est tout.

 
oui, sur plusieurs projets. Et s'il n'y a pas UNE bonne façon de faire, il y en a des mauvaises, dont la tienne.
 

 
Encore une fois tu confonds "ce qui se fait" et "MVC".

Je sais pas ce qu'est pour vous (dans votre cas) une vue, mais en Zend Framework c'est de l'HTML.
 
Et je me vois mal au début de mes PHTML avoir du code PHP de traitement.
 
Pour des cas simple au mieux ça donnerais ça :

Là on se dit super, ça marche trop bien, c'est super simple. (y'a même rien dans le contrôleur en fait)
 
Mais s'il y a des paramètres, genre pour une filtrage ou une pagination, le contrôleur va les passer à la vue, et la vue fera peut-être un traitement un peu plus compliqué et on risque d'avoir un beau :

Autant tout faire dans un contexte PHP pur, c'est juste plus lisible et compact à mon sens.
 
Comme dit, c'est ce qui est préconisé par plusieurs livres sur Zend Framework, donc j'ai sans doute été formaté comme ça.

Pour ça que dans mon framework je peux surcharger la classe vue à côté de la template pour offrir des méthodes ou pour préparer les données

C'est une des choses impossible en Zend Framework.
On associe forcement des variables à la vue du contrôleur, qui seront accessibles par la template.
 
Sinon, il faut forcement travailler dans la template.

Tu peux pas hériter de Zend_View et y mettre des trucs en plus

Zend_View c'est plus la mécanique bas niveau qui importes les filtres/aides de vues et fait le rendu des templates.
 
Ce n'est pas impossible de changer la vue dans une action, mais ça serait plus dans l'optique de modifier le comportement.
Alors du coup, si on veut reproduire ce que fait ton framework, il faudrait se créer son Zend_View personnalisé qui automatiquement ferais le liens vers des classes de vue orientés traitements.
 
Bref, ce n'est plus du Zend Framework de base, mais bel et bien se constituer son framework personnel en se basant sur Zend Framework.
A voir ce que ça donnerais en pratique.

Je vois justement Zend_Framework comme une grosse librairie de composants, avec lesquels tu peux toujours faire ta propre tambouille

 
Holy fucking shit

Tout ça pour dire, autant prendre un microframework

vous etes en train de parler de l difference entre une archi mvc et une archi 3tiers , c'est bien ca?  
 
car effectivement je pense que ce que je suis en train de faire c'est du 3tiers plutot que du mvc , car ma vue demande au controller et non pas ma vue demande directement au modele . c'est bien ca ?  
 
j'ai du mal dans un programme lineaire comme php a comprendre comment la vue peut demander au modele sans passer par le controller  
 
parce que dans la pratique la vue ne demande rien au modele , ni a qui que ce soit , dans la pratique je fais une requete "affiche moi la liste " au controller qui recupere les données puis les envoie a la vue  
 
a aucun moment une requete peut aller de la vue vers quelqu'un d'autre puisque la vue en tant que telle ... c'est une vue .  
 
je rate quelque chose quelque part, si tout cela a du sens pour une application qui reste ouverte je ne vois pas comment le transposer dans une appli php , une fois que la page est executée; elle est executée.  
meme si je fais un systeme d'observation qui une fois trigguée renvoie les données en ajax et adapte la vue , il y a quand meme eu obligatoirement une requete  au controller .  
 
le vrai modele mvc est il adaptable pour une page web?  

 
La vue demande au contrôleur qui éventuellement demande au modèle, c'est ça le MVC.

 
et bien non  
 
je lis souvent des tutos qui disent qu'en mvc la vue PEUT directement interroger le modele.  
 
ce que je fais moi c'zest comme tu dis , c'est ma vue qui demande a mon controler qui demande au modele qui renvoie au controller qui renvoie a la vue  
 
et voila le soucis .  
certains appellent ca nTIERS , d'autres appellent ca mvc
C'est du mvc par definition mais j'ai l'impression que c'est plus contraignant que le concept de base mvc .  
 
or je ne vois pas d'autres maniere de faire. ///