Forum: Rails France Bonnes pratiques pour les formats des actions

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

> 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.

>
> > 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 Belleville

Fernando Perez 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 Catty || fuse
http://www.noremember.org

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 Catty<martin@noremember.org> a écrit :

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 Blanco <slainer68@gmail.com>

> 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.

2009/6/22 Fernando Perez <list-incoming@andreas-s.net>

>
> > 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 Belleville

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 Belleville


2009/6/22 Emilien Taque <etaque@gmail.com>

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 Belleville <michel.belleville@gmail.com>

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 Belleville


2009/6/23 Emilien Taque <etaque@gmail.com>