Bonnes pratiques pour les formats des actions

Community FR
1

Bonjour à tous,
Je me pose la question de la meilleure manière de gérer les formats
d’actions.
Est-ce qu’après un scaffold, vous gardez le bloc format ?

respond_to do |format|
  format.html # index.html.erb
  format.xml  { render :xml => @cards }
end

Si oui, gardez-vous la réponse HTTP “406-innacceptable” par défaut ?
Si non, faites-vous un rescue de l’exception “Template is missing”
pour répondre du 406 ou du 404 ?

Merci
Emilien

2

Est-ce qu’apr�s un scaffold, vous gardez le bloc format ?
Je n’utilise pas le scaffold. Et pour envoyer du xml par exemple je crée
une view avec builder.

J’ai jamais compris à quoi servait ce bloc respond_to et format.xml. Ca
permet de sortir du xml sans avoir à coder la moindre vue? C’est un
intérêt assez limité si c’est ça.

3

Est-ce qu’apr�s un scaffold, vous gardez le bloc format ?
Je n’utilise pas le scaffold. Et pour envoyer du xml par exemple je crée
une view avec builder.

J’ai jamais compris à quoi servait ce bloc respond_to et format.xml. Ca
permet de sortir du xml sans avoir à coder la moindre vue? C’est un
intérêt assez limité si c’est ça.

Ca dépend. Si ton but est d’offrir un webservice rest à peu de frais,
c’est
un moyen quasi idéal. Pas besoin de perdre du temps à faire du mapping
modèle <=> (xml|yaml|json) si ton modèle suit les conventions il est
“propre” vu de ces formats. Le fait de “ne pas avoir à coder la moindre
vue”
ça a un impact énorme sur :

  • la complexité de ton appli (pas d’ajout de couches de complexité Ã
    chaque
    cycle de développement successif, ton modèle change => ta vue s’adapte
    toute
    seule)
  • le temps de développement (pas de temps à passer à coder des vues qui
    ne
    sont que des représentations brutes des données de toute façon, moins de
    complexité = moins de temps à débugger)
  • ta tranquilité d’esprit (moins de complexité => moins de risques
    d’effets
    de bord)
  • le moral de ton équipe (coder des vues pour faire du XML c’est chiant,
    si
    si, la preuve : même une machine peut le faire toute seule)

Après si c’est le côté “faire un webservice” qui te semble douteux,
voici un
petit exemple :

  • Je fais une appli bourrée d’AJAX, qu’est-ce que je préfère, faire
    plein
    de vues pleines de bouts d’HTML à coller dans des espaces différents
    de mon
    appli mais représentant la même donnée ? Non, moi je préfère répondre
    en
    JSON avec les objets demandés et laisser jQuery faire mes bouts de
    vue,
    parce que jQuery connaît mieux le contexte, étant chez le client,
    alors que
    mon contrôleur chez le serveur préfèrerai ne pas avoir à tenir compte
    du
    contexte pour répondre, merci bien.
  • Je suis une petite équipe de développeurs qui veut faire un jeu en
    ligne avec un frontend qui pulse en flash (qui aime bien lire du
    xml), mais
    je veux avoir notre base de données backée avec appli intranet pour
    pouvoir
    toucher aux paramètres du jeu et gérer les transitions des phases.
    Hop un
    petit webservice séparé, avec des modèles qui n’affichent que les
    infos
    auxquelles le client peut accéder, et du côté “sérieux” notre belle
    appli
    intranet en Rails classique.
  • Je veux rendre notre service de cartographie des fromages français
    en
    ligne accessible avec une appli iphone. Le yaml passe de l’appli web
    au
    petit bidule tactile et délivre juste la bonne dose d’information
    plutôt que
    du gros HTML encombrant.
  • etc.

Ca a plein d’utilités, ca dépend de tes besoins.

Michel B.

4

Fernando P. a écrit :

J’ai jamais compris à quoi servait ce bloc respond_to et format.xml. Ca
permet de sortir du xml sans avoir à coder la moindre vue? C’est un
intérêt assez limité si c’est ça.

Limité ? C’est «juste» très pratique quand tu veux faire un webservice…

–
Martin C. || fuse
http://www.noremember.org

5

Et au final, vous faites comment pour les formats “inexistants” ? 404,
406 ?
Vous n’avez pas de petit malin qui s’amuse à triturer vos urls ?

2009/6/22 Nicolas B. [email protected]

6

Limité ? C’est «juste» très pratique quand tu veux faire un webservice…

D’accord là je comprends l’utilité, on peut pas faire plus low-cost.

7

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

Limité ? C’est «juste» très pratique quand tu veux faire un webservice…

D’accord là je comprends l’utilité, on peut pas faire plus low-cost.

:low_cost != :low_service
=> true

Michel B.

8

Bah ouais. Ça permet surtout de renvoyer quelque chose si une vue
n’est pas nécessaire : code d’erreur/statut, fichier, méthode d’objet
renvoyant directement ce qu’il faut (ex. to_xml), etc.

Nicolas (Novelys).

Le 22 juin 2009 15:28, Martin C.[email protected] a écrit :

9

Hum…
C’est effectivement ainsi que je procède :

rescue_from …, ActionView::MissingTemplate, :with =>
:route_not_found

Ces messieurs de Rails répondent par défaut avec du 406 (“not
acceptable”),
page blanche dans le navigateur, d’où mon questionnement.

Joker, Jean-Pierre ?

2009/6/23 Michel B. [email protected]

10

De toute façon, tant que c’est du 400 c’est déjà pas mal. Après, mettre
du
406 quand le client demande quelque chose qui n’existe pas avec une
requête
HTTP qui est acceptable je ne pense pas que ce soit vraiment la
description
idéale quand même, mais les développeurs Rails font ce qu’ils veulent.

Michel B.

2009/6/23 Emilien T. [email protected]

11

Attends, laisse-moi réfléchir, 404 c’est l’erreur quand quelque chose
n’existe pas, et la question c’est comment on fait pour répondre qu’une
ressource n’existe pas ?.. Arf, c’est compliqué, je vais demander le
2/4
Jean-Pierre… Ah, il n’y a qu’une réponse ? Alors j’appelle un ami…
Mince, j’ai pas d’amis.

Que ce soit parce que toto.js ou albert.js ou albert.xml ou
/products/1525.html n’est pas censé exister, si ce n’est pas censé
exister
ce n’est pas censé exister, donc c’est 404.

Michel B.

2009/6/22 Emilien T. [email protected]