Reprise du message précédent :

Si c'est grâce à nous c'est pas bien, si c'est grâce à toi et la doc c'est mieux

 
C'est un tout.

Bonjour !
Bon, je vais passé pour un boulet mais bon...
 
Je tente d'apprendre le MVC un cherchant sur le net, et je voudrais savoir si mon cas ci dessous est "correcte" ( au niveau de la séparation des couches)
 
PS : le code est pourri, c'est jsute pour l'exemple.
 
controleur:

 
modele:

 
vue:

 
Merci  

Ouais ça y ressemble vaguement
 
Après model_news devrait être un objet plutôt qu'une fonction, avec des méthodes pour sélectionner, insérer et modifier des news. Ou alors renommer la fonction model_news en select_news ?

Oui oui, ça va de soit pour programmer en objet
 
C'était vraiment un exemple simple pour séparer les 3 couches sans trop réfléchir au code pour le moment    
 
Merci pour la réponse

Sur Symfony, est-ce qu'il ya une fonction pour récupérer directement l'année de création d'une entrée dans une table (en se servant du champ created_at) mais sans passer par les fonctions "traditionnels" de PHP de manipulation de date ?

Avec Doctrine non, une date n'est rien d'autre qu'une chaine de caractères formattée.
 
Par contre le plugin sfDate te permet de jouer facilement avec les dates.

$obj->getCreatedAt('Y');

Avec Propel seulement

Merci pour les réponses (bon dommage je suis sous doctrine)

sfDate::getInstance($obj->created_at)->getYear(); n'est pas très compliqué non plus

On est bien d'accord que le Modèle stocke l'état de l'application ?
 
Donc  
- l'user actuellement loggé,  
- certains bouts de contexte  
- certains bouts de configuration
- le traitement des fichiers quand c'est le rôle de l'appli
font théoriquement partie de la couche modèle ?

oui.
Même si "le traitement des fichiers quand c'est le rôle de l'appli" c'est pas super clair.

Genre l'encodage de vidéos pour Youtube

Ça a pas de sens ça, il n'y a pas un user actuellement loggé, surtout sur du web où les connections sont stateless. Le concept de "user actuellement loggé" en web, c'est scopé sur une requête (avec un scoping session qui est plus un hack qu'autre chose).
 
Tu peux stocker les données des différents users dans le modèle (normal), à la limite les données d'users ayant récemment été loggés (genre les contenus de session), mais je vois pas comment tu peux stocker "l'user actuellement loggé".

Tu va pas me dire que conceptuellement, il n'y a pas UN utilisateur loggé ?

Et puis le modèle, lui, il s'en fout que ce soit du web ou pas devant lui... nan ?

Techniquement c'est stateless mais conceptuellement, pas forcément (si il y a des sessions ou autre)...

Bah si.

Théoriquement ptet, pratiquement pas vraiment

 
Question piège, ça.
Si tu y réfléchis un peu c'est théoriquement le même problème que l'échappement de la saisie des utilisateurs...c'est une contrainte liée au réaffichage, donc c'est le boulot de la vue amha.
M'enfin je pense pas que quelqu'un t'en voudra si tu considère que l'encodage est plutôt contraint par le stockage et le délai de restitution dans le format demandé par la vue, et que c'est donc le boulot du modèle.
Tout dépend comment tu te places, et ce que tu veux stocker. Est-ce que tu veux garder l'original et générer aussi le flash au moment du stockage pour une restitution adaptée? Est-ce que tu as des machines de compète et tu génères le flash à la volée à-partir des originaux? Est-ce que tu considères que les originaux pour ta plate-forme sont les versions flash?

Sauf que moi je parle de théorie.
 
Et qu'en pratique, c'est très facile à implémenter...
 
 
Par ex, je fais un site multi-shops (multi-urls etc). Je stocke le shop courant dans le Modèle après analyse de la requête.
Je pourrais très bien faire pareil avec l'user (en l'occurence je le fais pas car j'utilise un plugin externe).

Et à chaque requête tu re-stockes ton "shop courant" dans le modèle. T'as pas l'impression qu'il y a comme un problème?

Lequel ?
En quoi c'est moins bien que de le stocker dans le controller ou dans un endroit non identifié ?

Wut?
La vue analyse la requête, fournit les infos dont il a besoin au controleur, qui peut alors instancier le shop adéquat pour lui faire faire l'action demandée...non?

Là je vois vraiment pas comment ça peut fonctionner en pratique
 
Shop->displayHomePage() ?

c'est la vue qui analyse ?  
pour moi , c'etait le role du controleur,non?

 

Dans le cas d'un affichage l'action demandée c'est la restitution des données nécessaires à l'affichage...que le contrôleur va refiler à la vue, qui va les afficher...

Bah tu stockes dans ton modèle une donnée transiente qui a comme durée de vie ta requête

Non mais il n'y a rien à stocker, les trucs "courants" (utilisateur courant, shop courant) ce sont des données controller permettant de moduler les interactions avec le modèle (perm checks & autres), ça n'a rien à faire dans le modèle, c'est pas du tout la même scope, une application tierce n'en a rien à foutre de l'utilisateur ayant une requête en cours d'exécution à l'instant t.

théoriquement non - le format de la requête est dépendant de la vue (le contrôleur se fout de savoir si un formulaire est en GET ou en POST, par exemple - ce qu'il veut savoir c'est ce que l'utilisateur a demandé).
Si tu préfères, la vue décode la requête pour la présenter au contrôleur dans un format qu'il comprend, et ce dernier analyse ce qu'on lui donne.

Sauf qu'elles sont aussi nécessaires à tous les appels au modèle que va faire le controlleur...
 
Pourquoi renvoyer le shop en argument tout le temps, alors que je peux le stocker dans le modèle et que c'est tout-à-fait MVC-compliant ?

 
M'enfin, le shop est DANS le modèle.

Je sais pas si c'est que tu sous-entends, mais je ne le stocke pas dans la BDD hein, juste dans la couche objet (qui elle aussi a comme durée de vie la requête)

Ca c'est la représentation technique du fait que t'es en web, pour une appli bureau tu raisonnerais pareil ?

Les trucs "courants" c'est pas justement tout ce qui fait qu'une application a un état (simulé ou pas) ?

   
On doit pas avoir la même idée du mvc mais clairement traiter ce qui est routing d'url et ce qui a trait au http (dont la méthode) c'est bien le rôle de la partie controller, je vois pas ce que la vue fait ici, elle est simplement appelée à la fin pour mettre en forme les données qu'on lui passe
 

+1
Le controlleur va demander tel enregistrement du modèle shop et vérifiera telle option de config ou tel droit, mais le modèle s'en fiche de savoir qu'a chaque requête on récup un shop par exemple

Oui.

En fait pour toi le modèle stocke l'état de l'appli sur le "long terme" (BDD), mais pas le court terme (session/requete en cours) ?

J'ai bon ?

Si oui, qu'est-ce que serait le modèle dans une appli comme un traitement de texte, qui n'a pas d'état sur le long terme (à part la config ou 2/3 features, quoi...) ?

Oui.

le document en cours d'édition, ça me semble être du long terme

Effectivement on n'a pas la même idée du MVC - tu es clairement influencé par les implémentations "web" existantes, et ce que je décrivais est plutôt une application "idéale" (d'un point de vue conceptuel, pas forcément pratique) du pattern.
 
La "Vue" est censée gérer l'intégralité de l'interface avec l'utilisateur - en faisant traiter les urls au contrôleur tu introduis un lien fort entre le contrôleur et l'interface utilisateur, ce qui est contraire au principe de base de MVC.

 
Je vois ce que tu veut dire, en effet j'ai plus une vision très orientée web mais d'un autre côté on est dans la cat php

Tout à fait...mais ce point est précisément une des critiques qui revient souvent sur tous les frameworks web pseudo-mvc...

N'est-ce pas tout simplement MVC qui montre ses limites dans un environnement web ?
 
Let's think beyond MVC...

Pourtant il dure la durée d'une session, au maximum

Hum non, le document édité, s'il est sauvegardé, dure jusqu'à ce qu'on le supprime

Bah, un MVC plus strict est sûrement faisable déja : si la vue envoie un type de contenu, c'est normal que ce soit elle aussi qui gère sa réception... Et tout le routing serait dans la vue, logique.
 
Forcément ça va encore déborder un peu dans le controlleur, mais moins.
 
La vue serait la face visible, elle gère tout le protocole HTTP et serait ainsi à la limite interchangeable avec une UI bureau (ouais c'est théorique ).