Créer un assistant qui fonctionne avec plusieurs ressources

J'écris une application qui a une section d'entrée de type "assistant". Pensez aux installateurs MS Windows.Créer un assistant qui fonctionne avec plusieurs ressources

Je n'arrive pas à trouver la façon la plus RESTful de le faire avec des rails. Je peux y arriver d'une manière non reposante (déjà fait pour la version 1 de l'application), mais j'essaie d'être un peu plus idiomatique cette fois-ci.

Voici la situation. J'ai un assistant en 5 étapes qui doit rassembler des informations. Les étapes 1, 2 et 4 traitent de la ressource A. L'étape 3 traite des multiples de la ressource B et doit les associer à la ressource A. L'étape 5 est juste une confirmation. J'ai donc mon resourceA_controller et mon resourceB_controller ... mais ils ne sauvegardent/mettent à jour que cette ressource. Je devine que je devrais mettre en place un wizard_controller pour chacune des étapes du processus, mais je ne suis pas sûr de savoir comment le routage devrait fonctionner.

Par exemple ...

WizardController < ApplicationController 
    def stepOne 
    @resourceA = ResourceA.new 
    end 
    def stepTwo 
    @resourceA = params[:id] 
    end 
    ... 
    def stepFive 
    end 
end

Et j'aurais mon avis être sur le point de vue StepOne:

<form action='/resourceA/new'/>

et sur l'action StepTwo

<form action='/resourceA/12345/edit'/>

etc.

Mais alors mes contrôleurs resourceA et resourceB devraient savoir comment rediriger vers l'étape appropriée dans le wizard_controller. Bavardage emmêlé!

Est-ce que je suis près de la bonne voie? Ou y a-t-il un mécanisme intégré de rails ou un plugin qui fait ce genre de chose.

Source

2009-10-19 Mike

Il est important de comprendre la distinction entre ce que REST fournit et ce que REST ne se soucie pas.

Un service RESTful fournit un ensemble minimal d'actions qu'un client peut utiliser (à condition qu'il connaît le format de données approprié) pour manipuler une classe de ressources
- Par exemple, vous devriez être en mesure de POST /resourceA/12345 pour modifier cette ressource existante
Un service RESTful ne fait aucune garantie sur lequel d'autres URL seront de retour des réponses significatives.
- Un exemple notable est que le repos ne précise pas que /resourceA/12345/edit retourne un formulaire HTML conçu pour l'édition de cette ressource. C'est une fonctionnalité de l'application HTML qui fournit simplement une méthode d'exécution du POST décrite ci-dessus.
- L'extension de cette théorie, il est parfaitement acceptable d'avoir plusieurs formes d'édition qui sont tous POST à l'URL RESTful définie. Depuis utilisera généralement à masse affecter ce qu'il est passé l'action edit du contrôleur, vous pouvez regarder les attributs transmis, ainsi que des informations sur quel bouton HTML a été utilisé pour soumettre le formulaire, pour décider quelle page l'utilisateur doit voir à côté. Il peut être effrayant de s'appuyer sur une seule méthode de contrôleur pour gérer les soumissions de plusieurs pages, mais avec une validation intelligente et l'écrasement sélectif des accesseurs, vous pouvez maintenir un grand contrôle sur la façon dont les utilisateurs accèdent à l'application.
- Vous devez également être en mesure de travailler que cette méthode ne limite pas les utilisateurs à envoyer uniquement les attributs dans l'ordre présenté sous la forme. Un autre client RESTful pourrait en théorie des mises à jour de POST pour tous attributs associés à une ressource, plutôt que ceux qui sont présentés par une page de votre assistant. En supposant que vos méthodes de modélisation sont assez robustes, tout peut être fait pour Just Work.

Source

2009-10-20 00:12:07 Gareth

C'est à peu près ce que je pensais si je n'étais pas claire. Je ne savais pas si gérer la logique de routage de mes contrôleurs était tout à fait logique. Voir quelqu'un d'autre confirmer cela est utile. – Mike