Les limites de la vue

[devlop78]

Bonjour,

Après avoir réduit mes controlleurs pour faire le gros du boulot au modèle, je m'attaque à la vue. En effet, dans le layout, j'utilise un partialLoop() sur un tableau avec des entrées diverses (c'est une liste de liens). Or, ces liens ne peuvent être déterminés par la vue.

Alors, je me suis ainsi posé la question : est-il normal (ou bien) de justement mettre

Code :

$this->url(array(...), 'routeur', bool)

Dans une vue. D'autant que récemment j'ai transformé mes Rowset lu par la vue en array(), et mes appel à Zend_Auth dans la vue, par simplement une variable $userName. Ainsi, le controlleur s'occupe des données, et la vue ne fait que les afficher sans logique particulière.

Pour le url(), c'est autant une question de "bonnes pratiques" que de réflexion : il m'arrive de modifier les noms des actions ou de controlleurs, j'utilise une recherche de fichier pour ça, mais quelque part, est-ce vraiment de la responsabilité d'une vue de composer une url (et de le savoir). D'autant, que si demain je crée une vue XML ou JSON, je devrais faire une redodance d'appel et que modifier l'action reviendrait à modifier tous ces fichiers, alors que la vue ne devrait être là que pour adapter les données au contexte HTML (non ?). D'ailleurs pour le JSON, je me passe de la vue (j'envoie des données brutes, mais je n'attends pas que mon destinataire fasse une valeur ajoutée comme celle citée avec les données envoyées. Dans le cas d'une URL, je lui envoie une URL composée, et non pas à lui de la composer avec un nom d'action qu'il aura stocké qq part).

J'imagine que dans le cas d'une itération, je peux faire :

Code :

1
2
]$this->view->urlFormat = $this->_helper->url(array(.., 'grille' => '%s'));
$this->view->elements = array('salut'=>'125', 'bonjour'=>'189');

Et dans la vue :

Code :

1
2
3
4
foreach ($this->elements as $name=>$value)
{
   echo '<li>'.sprintf($this->urlFormat, $value).'</li>';
}

Si ce n'est le détail technique que %s est modifié par urlencode (mais j'ai bien dit détail non ?).

Quel est votre avis ? Avis de "puriste" je parle : on est d'accord, la bidouille et les exceptions sont toujours permises. Qui peut le plus (== "le mieux") peut le moins.

Merci par avance à vous, et cordialement,

[GrandFather]

Tu les modifies si souvent que cela, tes noms de contrôleurs et d'actions ? Je pose la question, parce qu'il me semble excessif de définir une façon particulière de coder tes vues et tes contrôleurs en vue d'un hypothétique refactoring.

D'un point de vue purement conceptuel, il me semble normal que les liens soient construits dans la vue. Un lien est un élément d'IHM, il doit donc être construit dans la vue. Maintenant, si tu veux que lors d'un refactoring tu n'aies pas à changer le code de tes vues, il y a un moyen simple: Créer une classe descendant de Zend_View, comprenant une méthode allant chercher à son initialisation les éléments constituant des URL (nom des contrôleurs et actions) dans un fichier INI et les stockant dans un champ de l'objet (tableau associatif). Ensuite, dans tes vues, tu n'as plus qu'à faire référence à ce champ pour construire tes liens.

En cas de changement, tu n'as que ce fichier INI à modifier. Tout le reste, vues et contrôleurs, reste inchangé.

[devlop78]

Hmm ... Non je ne les change pas super souvent, mais quand je suis en mode "reflexion" oui

Je ne sais pas si la réflexion d'IHM peut être vraiment vu comme ça sur le web. L'utilisateur voit un lien qui a été au final sorti par la vue (mais laquelle ? Celle de HTML, de XML - Ce n'est pas une vraie question), mais lorsqu'il clique, ce n'est pas la vue qui redirige mais le dispatcheur, grosso modo le controlleur frontal. Au final, c'est quand même au Controleur (architecturalement parlant) qu'imcombe la responsabilité de définir quelles sont ces routes, ces "url". Enfin, c'est mon avis. Ensuite, la vue peut-elle le faire ? Si il y a une aide de vue url(), c'est probable, mais pas forcé.

La démarche est souvent difficile : Jusqu'où la vue doit-elle et peut-elle être responsable. Après la lecture d'un article, j'ai arrêté de transmettre des Rowset du modèle à la vue, je lui transmets plus que des tableaux. Ok. Ensuite, je me suis dit sur le même principe, pourquoi manipulerait-elle Zend_Auth pour afficher un bouton de connexion ou de déconnexion ? Du coup, comme j'avais déjà ce gros soucis de "code" dans le layout, j'ai décalé ce travail avec un plugin réservé au layout (une sorte de controlleur spécialement pour le layout).

Il ne me choquerait pas de me dire que la vue ne fait que représenter du html à partir de données, ou du xml à partir de données, mais qu'à aucun moment elle n'en traite (demander un url() c'est déjà avoir la responsabilité de connaitre des données que le controlleur ne lui a pas passé, sauf si c'est de paramètres passés).

Le plus simple, aurait été un article décrivant précisemment la responsabilité de chacun. Mais si forcément, il faut taper "fat model, skinny controler" pour avoir des débuts de réponses, alors il faut tomber dessus au hasard.

[GrandFather]

Envoyé par devlop78

Il ne me choquerait pas de me dire que la vue ne fait que représenter du html à partir de données, ou du xml à partir de données, mais qu'à aucun moment elle n'en traite (demander un url() c'est déjà avoir la responsabilité de connaitre des données que le controlleur ne lui a pas passé, sauf si c'est de paramètres passés).

Au contraire, utiliser l'aide de vue url() permet à la vue de s'affranchir du type de routage utilisé. Si du jour au lendemain tu décides pour une raison quelconque de passer par exemple de l'URL rewriting à une autre forme de routage, tu n'auras pas à retoucher tes vues.

Sinon, pour le reste je suis d'accord avec toi. Passer un tableau plutôt qu'un rowset est une démarche saine ; la vue n'a pas à « connaître » les détails d'obtention des données, elle doit se contenter de les afficher. Passer un tableau est une bonne pratique, on introduit ainsi un niveau d'abstraction entre le modèle et la vue.

[5h4rk]

Une petite règle de bon sens en développement :

Ne pas modifier quelque chose qui fonctionne déjà au risque d'avoir plusieurs régressions ne pouvant être contrôlé.

Il vaut mieux utiliser les interfaces, les façades, l'héritage.