2009-11-11 8 views
0

J'ai un formulaire qui, sur submit, demande au client de vérifier les données, puis de confirmer les modifications avant d'enregistrer les données.Meilleure façon de conserver les données de formulaire sur la redirection manuelle arrière?

Cependant, j'utilise une manière très approximative de conserver des données si l'utilisateur appuie sur le bouton de retour pour revenir en arrière et regarder les données avant de les soumettre. Puisque je veux que les mises à jour de l'utilisateur soient dans les champs et non dans les champs de la base de données courante, pour être ce qui s'affiche sur cette action "retour", je dois passer les valeurs via les paramètres post/get. Donc, mon contrôleur ressemble à quelque chose comme:

@customer = Customer.find session[:id] 
    unless params[:customer].nil? 
     @customer.attributes = params[:customer] 
    end 

Y a-t-il une meilleure façon de procéder? En fait, je suis vraiment curieux de savoir quelle est l'utilisation de la session Rails généralement acceptée, car je suis certain que l'utilisation de la session pour transmettre des informations comme celles-ci est taboue. Oui Non? Pensées? Merci.

Répondre

0

Il peut y avoir une meilleure façon de le faire impliquant des sessions. Je préfère éviter complètement l'utilisation du hash de session, avec une deuxième forme et beaucoup de javascript.

Voici comment je le manipulerais. Le premier formulaire ne changerait pas du tout, il suffit de soumettre à une nouvelle action appelée révision. L'action de révision affichera les changements pour révision, et aura un lien d'édition et un bouton de confirmation visibles. Il recréera également le formulaire de la page précédente dans un élément caché qui sera soumis à nouveau à l'action de révision.

Le bouton de validation serait soumis à votre action de mise à jour.

En cliquant sur le lien d'édition, vous masquez la zone de révision et affichez la zone dupliquée à partir de la page précédente.

Voici quelques exemples de code pour marteler vers le bas le point:

app/controllers/example_controller.rb

class ExampleController < ApplicationController 

    def edit 
    @example = Example.find(params[:id]) 
    end 

    def review 
    @example = Example.find(params[:id]) 
    @example.update_attributes(params[:example]) 
    @example.valid? 
    end 

    def update 
    @example = Example.find(params[:id]) 
    @example.update_attributes(params[:example]) 
    if @example.save 
     redirect_to @example 
    else 
     render :action => :review 
    end 
    end 
end 

app/views/examples/_form.html.erb:

<% form_form @example, :url => {:action => "review"} do |f|%> 
    ... 
    Form inputs go here 
    ... 
<% end %> 

app/views/examples/edit.html.env:

<%= render :parital => form %> 

app/views/examples/review.html.erb:

<div id="review"> 
    ... 
    content for review goes here 
    ... 
    <%= link_to_function "Edit", "$('review').hide(); $('edit').show()" 
    <% form_for @example do |f| %> 
    <%= hidden_field :attribute, @example.attribute %> 
    ... 
     hidden_field for each attribute 
    ... 
    <%= submit_tag "Accept These Changes" %> 
    <% end %> 
</div> 
<div id="edit" style="display:none"> 
    <%= render :partial => 'form' %> 
</div> 
+0

donc sont-ce que vos show éléments cachés en utilisant ajax/javascript ou sont-ils en pleine page réoriente? – Lukas

+0

Je pensais être clair, en ce sens que c'était juste Javascript, mais je suppose que non. J'ai ajouté un exemple à ma réponse. – EmFi

+0

Je me sens comme si vous pouviez sortir avec le review.erb, et avoir le div "edit" en premier, puis quand vous cliquez sur "submit", il se cache et affiche le formulaire de révision. C'est juste une observation cependant. Je suis plus curieux de savoir comment faire si je devais le faire sans javascript. Même si je devais utiliser JS, je voudrais être compatible avec JS-disabled. Bien que je sois d'accord, c'est un moyen facile de le faire, je ne suis pas sûr de pouvoir le faire * seulement * de cette façon. – Lukas

Questions connexes