> > > 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 --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] -~----------~----~----~----~------~----~------~--~---
