De la maintenabilité des views

Community FR
1

J’ai un gros problème avec les views. Plus mon application grandit, et
plus les modèles vont se retrouver afficher dans différentes views ce
qui augmente la potentiel de bug lorsque je modifie l’attribut d’un
modèle.

J’ai testé plusieurs choses:

  • écrire des kilomètres de tests pour m’assurer que les views sont bien
    affichées
  • tenter de mettre du code de la view dans le modèle
  • utiliser des partials
  • tenter d’écrire des views abstraites utilisables par n’importe quel
    model, surtout pout les formulaires qui se ressemblent quasiment tous.
  • autre?

Aucune des solutions que j’ai essayé ne m’a plu jusqu’à présent. Comment
gérez-vous ça? Est-ce que vous avez des astuces, Design Pattern, etc Ã
partager?

2

Et utiliser du javascript pour aller chercher les différentes composants
d’une page? De cette manière, je sais que si je change un model, seules
ses views dans le répertoire /model/* seront susceptible d’exploser, et
pas une view au fin fond du site.

3

Le 21 juin 2009 14:56, Fernando P. [email protected] a
écrit
:

  • utiliser des partials
  • tenter d’écrire des views abstraites utilisables par n’importe quel
    model, surtout pout les formulaires qui se ressemblent quasiment tous.
  • autre?

Aucune des solutions que j’ai essayé ne m’a plu jusqu’à présent. Comment
gérez-vous ça? Est-ce que vous avez des astuces, Design Pattern, etc Ã
partager?

Bonjour,

Je n’ai pas encore été confronté à un gros volume, mais comme ça, je
dirais
que des partials bien fait et bien placé évite la redondance. Ajouté Ã
quelques test d’intégration, voir des tests de recette (existe-t-il une
application type “fitness” pour ruby ?).

Les solutions genre mettre du code de vue dans les modèles, ou faire des
vues abstraites me paraissent un peu délicat.

Bon courage.

–
Yannick F.
http://kantena.com

4

Mettre du code de vue dans les modèles, faire des vues abstraites…

…comme…

…des helpers ?

Je dis ça comme ça, mais le helper permet de mettre du code compliqué de
présentation hors des vues…

Michel B.

5

Tester fonctionnellement ses vues avec Webrat ?

Nicolas (Novelys)

Le 22 juin 2009 20:11, Michel B.[email protected] a
écrit :

6

Nicolas B. wrote:

Tester fonctionnellement ses vues avec Webrat ?
Je le fais déjà avec test::unit et c’est ultra chiant. Et webrat est
d’une lenteur à en mourrir…

Je vais tenter de tout mettre dans les helpers qui sont unit-testable
donc plus simple à gérer.

7

On 21 juin, 14:56, Fernando P. [email protected] wrote:

J’ai un gros problème avec les views. Plus mon application grandit, et
plus les modèles vont se retrouver afficher dans différentes views ce
qui augmente la potentiel de bug lorsque je modifie l’attribut d’un
modèle.

Les partials sont faits pour ça : mutualiser un morceau de vue. Si ce
morceau est un algo un peu avancé, on préfère l’encapsuler dans un
helper. Une vue est juste sensée afficher des données préparées par le
contrôleur. Le potentiel de “bug” que tu évoques ne devrait pas être
si terrible. D’ailleurs, mes priorités pour les tests mettent la vue
en dernière position.

Quand on suit les conventions, la modification d’un modèle n’impacte
que peu de vues (“new” et “edit” dans ce que j’ai l’habitude de faire,
ainsi que “index” et “show” au pire des cas).

Ma certitude : la mauvaise solution est de mettre du balisage dans le
modèle ou le contrôleur.

En posant un cas pratique, tu auras peut-être plus de chances
d’obtenir des remarques pertinentes.

Julien

8

Autre chose : pas de rjs.

Je sais, le rjs c’est “sexy” et tentant, on met d’abord un ou deux
link_to_remote, et puis on y prend goût, on commence à faire des
remote_form_for, et très vite c’est le drame : on emploie des vues
javascript.

Et c’est là que commencent les problèmes, parce que la vue JavaScript
sait
qui elle est et ce qu’elle contient, mais pas où on va l’utiliser, et le
jour où on l’utilise dans deux contextes différentes on s’aperçoit
soudain
que le premier contexte contient une liste à puces nommé “companies”
alors
que la nouvelle présente une div nommée “customers” et que le contenu du
coup il rentre pas bien dans la 2°. Alors pour peu qu’on se dise “bon
ben je
vais rajouter un paramètre “target_id” à ma requête pour préciser le
contexte d’arrivée” on se retrouve très vite à avoir des ronces qui
poussent
dans le contrôleurs, le javascript est infesté par les alertes et l’AJAX
prend l’eau.

La bonne idée : utiliser jQuery en non-obtrusive, faire des format.js
qui
répondent du json avec juste les données qui vont bien, utiliser jQuery,
recevoir le JSON (ou le xml) avec une méthode de rappel appropriée et
repeupler le HTML avec des nouveaux éléments sur mesure (la méthode de
rappelle sait où elle est, elle), utiliser jQuery, en cas d’erreur
renvoyer
des codes erreurs HTTP correspondantes aux problèmes rencontrés (dans le
cas
d’erreurs de formulaire renvoyer les données d’erreur pour mettre des
champs
en rouge), utiliser jQuery.

J’ai mentionné jQuery ?

Michel B.

9

2009/6/23 Fernando P. [email protected]

Les partials sont faits pour �a : mutualiser un morceau de vue.
Oui mais alors ne pas les mutualiser entre les controlleurs, parce que
là ça devient ingérable.

Tant que ça reste bien fait (aka: un peu de documentation ne fait pas de
mal) et que le partial se contente de faire son boulot (de la
présentation)
je ne vois aucune raison de limiter un partial à un contrôleur.

10

L’exemple type de choses qu’il vaut mieux éviter dans un partial, mettre
un
élément englobant avec un id html :

...

Dès que tu vas avoir deux listes du même partial dans ta page (exemple
pour
faire un drag-and-drop) bonjour les gros emmerdes de doublons d’ids.

Dans ce cas là , mieux vaut laisser à le vue englobante (ou la méthode de
callback d’un chargement AJAX propre) faire le bon agent de circulation
en
lui laissant attribuer les ids comme bon lui semble.

Michel B.

2009/6/23 ook? ook! [email protected]

11

Les partials sont faits pour �a : mutualiser un morceau de vue.
Oui mais alors ne pas les mutualiser entre les controlleurs, parce que
là ça devient ingérable.