Discussion :

[laville]

Bonjour,

Je suis aujourd'hui confronté à un débat avec certains de mes collègues sur la meilleur façon d'implémenter la partie MVC dans ma société.

Cette problématique est au niveau de la vue et de classes métiers (qu'ils considèrent être lié au controller).

Prenez l'exemple de l'implémentation en PHP du fameux jqgrid. Nous avons donc là deux écoles :
- la première disant que tout ce qui est à la vue doit être écrit dans la vue (ou à la rigueur dans un helper de vue mais là dessus pas encore certain)
- la seconde, disant que dans la vue nous pouvons faire un simple 'echo" de l'objet qui utilisera la fonction _toString() qui est pour moi là pour ca.

Effectivement la seconde solution lie quelque peu la partie vue et métier.
Mais en mon sens, la vue dit bien qu'il faut afficher un tableau, et c'est la classe métier qui va elle générer comme il se doit le tableau.

Pour la seconde, aucune génération en PHP, pas de classe PHP manipulant le Tableau, tout est dans la vue.


Ce problème peut se retrouver aussi dans d'autres composants, à savoir le Zend_Form qui propose des décorateurs permettant la génération via un simple echo dans la vue d'un formulaire pouvant être complexe. La dessus aussi bien entendu ils sont contre car ils considèrent que cela n'est pas géré dans la vue et donc que l'on est pas MVC.


Merci donc de prendre le problème dans son ensemble et de ne répondre que si vous avez un avis très conceptuel de la chose, le but n'étant pas d'avoir des opinions personnelles, mais plutôt conceptuelles sur les bonnes pratiques à ce niveau là.

Merci d'avance pour vos lumières sur ce point

[MaitrePylos]

PHP n'est pas là pour manipuler le HTML.
On doit séparer le code PHP de HTML, donc la vue doit rendre uniquement le contenu, d'ailleurs le code PHP d'une vue ne doit permettre que de faire des parcours tableaux ou echo de variables, le tout bien entendu géré dans les controller et model.

Utilisateur intensif de ZF, je suis d'accord (heu oui c'est personnel) avec le fait que Zend_Form n'est pas MVC, je ne l'utilise jamais (trop d'heures perdue pour un simple formulaire).

Je me rangerais donc du côté de tes collègues !

[rawsrc]

PHP n'est pas là pour manipuler le HTML.

Euh, je pense qu'il ne faut pas être aussi restrictif. Il ne faut pas quand même oublier qu'une page web ce n'est que du texte. Donc ce n'est pas un non sens que d'utiliser PHP pour produire du texte à la volée, texte avec un formatage particulier certes, mais du texte quand même.
Après, séparer le HTML du PHP c'est une bonne pratique qui est à recommander fortement.

Je suis aujourd'hui confronté à un débat avec certains de mes collègues sur la meilleur façon d'implémenter la partie MVC dans ma société.

Bienvenu dans l'éternel débat concernant les interprétations du concept MVC.

La place de la vue est en bout de chaîne. La vue ne fait rien d'autre que générer du code qui sera envoyé au client à partir des paramètres qui lui sont spécifiques. Le code à générer peut être du HTML, XML, PDF....
Dans notre framework, une vue peut faire appel à d'autres vues mais à aucun autre type de composant. Par corrélation, on ne dérive pas les vues les unes des autres (pas de décorateur), les vues se résument à des briques individuelles assemblables les unes aux autres pour composer des rendus très complexes. Enfin, une vue ne fait que générer du code et rien d'autre (en particulier aucun envoi).

[laville]

PHP n'est pas là pour manipuler le HTML.
On doit séparer le code PHP de HTML, donc la vue doit rendre uniquement le contenu, d'ailleurs le code PHP d'une vue ne doit permettre que de faire des parcours tableaux ou echo de variables, le tout bien entendu géré dans les controller et model.

Effectivement je suis d'accord, la grande théorie veut cela mais souvent on fait au final :
- du contrôle de droit
- on implémente des règles métier selon tel ou tel paramètre
- etc.

Pour ma part, je suis pas en désaccord avec mes collègues, mais je serais plus souple. Zend_Form n'est pas réellement MVC (même s'il a des helper de vue qui font la génération HTML) mais pour moi il correspond à un besoin (et une fois le système compris cela va réellement bien crois moi, mais faut le comprendre...).
Il en va de même pour d'autres composants la jonction entre Vue et Controller est infime et complexe car :
- qui gère les inclusions de scripts dont on a besoin dans la vue ?
- qui gère l'affichage ou non de portions de codes ? Est-il nécessaire de faire plusieurs vues gérées par le controller pour réellement respecter le concept MVC ?

Si on veut du vrai MVC, avec une vue ne gérant que la présentation des données, on en revient inévitablement à une multitudes de fichiers appelés ou non par le controller... ou on crée des helper de vue utilisés par le Zend_Form.

Pour moi il y a une notion entre respect à 100% du concept et gain en temps (par exemple, peut-on dire que Smarty, générateur de template HTML assez reconnu, appartient à la vue ? Pour moi non il correspond aux helper de vue).

Mais malgré tout, je reste d'accord avec une personne qui me dit que conceptuellement un MVC, pour la partie vue c'est purement de la présentation. Après en réalité, il faut bien enrober cela car sinon cela nous ferait plus de travail / fichiers à maintenir que de gain réel apporté.

Bienvenu dans l'éternel débat concernant les interprétations du concept MVC.

Ah ça.... oui mais c'est ce qui est plaisant, si cela est fait intelligemment, le partage des opinions fait que chacun avance (on en apprend tous tous les jours et encore heureux, on revoit nos opinions sur certaines méthodologies et raisonnement, etc.).

La place de la vue est en bout de chaîne. La vue ne fait rien d'autre que générer du code qui sera envoyé au client à partir des paramètres qui lui sont spécifiques. Le code à générer peut être du HTML, XML, PDF....

Oui, mais exemple avec la génération csv etc. tu pourrais généraliser cela avec une aide de vue qui automatise cela au lieu de le duppliquer, pourtant c'est bien une classe qui va te le générer donc :
- gain important + réutilisabilité + maintenabilité contre :
- duplication de la fonction dans chaque vue

Au final, il semblerait qu'on soit arrivé à un consensus au niveau des aides de vue. Une classe, pour quelque rendu que ce soit (HTML, JavaScript, etc) doit passer par des helper.

Il me semble que ce soit une bonne pratique mais surtout un bon compromis entre respect des règles MVC et optimisation / réutilisation du code.

Qu'en pensez vous ?

[rawsrc]

Oui, mais exemple avec la génération csv etc. tu pourrais généraliser cela avec une aide de vue qui automatise cela au lieu de le duppliquer, pourtant c'est bien une classe qui va te le générer donc :
- gain important + réutilisabilité + maintenabilité contre :
- duplication de la fonction dans chaque vue

Au final, il semblerait qu'on soit arrivé à un consensus au niveau des aides de vue. Une classe, pour quelque rendu que ce soit (HTML, JavaScript, etc) doit passer par des helper.

On n'utilise aucun helper (au sens commun) et on ne duplique rien, dans notre framework chaque vue est une classe.

Voici un squelette de la gestion de cette problématique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
<?php
 
// 1ERE APPROCHE
$blk = new BLK_CreateFileCsv(); // la vue est une classe
$blk->params()->setData(...array...); //paramétrage
$blk->render();
 
 
// 2EME APPROCHE
// autres moteurs de rendu
class BLK_CsvEngine { }
class BLK_XlsEngine { }
class BLK_PdfEngine { }
 
class BLK_CreateFile {
 
   function params() { }
 
   function render() {
      if ($this->params()->format() === 'csv') {
         $blk = new BLK_CsvEngine();
      }
      else
      if ($this->params()->format() === 'xls') {
         $blk = new BLK_XlsEngine();
      }
      else
      if ($this->params()->format() === 'pdf') {
         $blk = new BLK_PdfEngine();
      }
      // on passe les données au moteur de rendu
      $blk->params()->setData($this->params()->data());
      $blk->render();
   }
}
 
// code qui pourrait être dans un contrôleur
$blk = new BLK_CreateFile();
$blk->params()->setFormat('csv');     // paramétrage en provenance du client
$blk->params()->setData(...array...); // paramétrage en provenance du modèle
$blk->render();
 
?>

Comme tu peux le constater, on assemble les vues et on ne fait rien d'autre. A la rigueur, organisé ainsi, on peut considérer que chaque vue est son propre helper. A toi de bien découper tes vues afin de pouvoir les réutiliser au maximum. Au final, tu ne fais que manipuler des classes pour tout : contrôleurs, modèles et même pour les vues.

[laville]

On n'utilise aucun helper (au sens commun) et on ne duplique rien, dans notre framework chaque vue est une classe.

Effectivement, mais dans le cas que tu me montres, helper (qui est une classe) ou ce que tu as écris, même s'ils ne portent pas le même nom (et qu'ils n'ont pas à 100% le même rôle) la logique reste la même.

Un helper de vue comme le headScript de Zend ne gère que la partie scripts, et faire une classe de gestion de scripts reviendrait au même enfin arrête moi si je me trompe (ou si je n'ai pas compris ce que tu voulais dire).

Un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<?php
$this-> headScript() -> appendFile($this->baseUrl().'/js/action.js');
?>
<button name="back" onclick="fonctionDansFichierAction()" >Retour</button>

Dans l'exemple, mon helper de vue a exactement le même but que ta classe
Donc séparation mais utilisation de classes (helper, classes de rendues, Smarty, etc.) qu'ils mettaient au départ comme appartenant à un controller (classe = C ou M et non V) mais à mon avis et d'après ce qui se dit au final, il y avait une incompréhension au niveau de classes de rendu (quelque soit leur rôle).