2012-02-21 3 views
4

Un avertissement rapide: Je suis assez nouveau pour Rails, et ma connaissance est un peu cookie-cutter-esque. Je sais comment faire certaines choses, mais il me manque cette compréhension vitale de la raison pour laquelle ils travaillent toujours.Comment utiliser Form_For pour mettre à jour un attribut de hachage dans le modèle

J'ai actuellement un modèle d'utilisateur qui a dans lui un tas d'information, comme l'adresse, l'email, etc. En outre, il a également un hachage appelé visible. Les clés de ce hachage sont chacune des informations, et la valeur est soit vraie soit fausse pour que l'utilisateur souhaite que cette information soit publiquement visible. Bien que je ne sois pas sûr que ce soit la meilleure façon de procéder, je ne vois pas d'autre moyen que de créer une tonne de variables booléennes pour chaque bit d'information. Enfin, je sérialiser: visible pour le stockage dans la base de données

Ce que je voudrais, c'est dans ma vue d'édition d'avoir une case à cocher à côté de chaque champ d'information qui représente l'attribut visible. Après avoir lu des tonnes d'autres articles liés à ce sujet et en essayant de nombreuses variantes de code, je finis toujours avec une sorte d'erreur. Le code qui ressemble le plus intuitivement correct pour moi est la suivante:

<%= form_for(@user, :id => "form-info-personal") do |f| %> 
... 
<%= f.label :name %> 
<%= f.text_field :name %> 
<%= f.check_box :visible[:name] %> 

Mais je reçois un message d'erreur indiquant qu'un symbole ne peut pas être analysé dans un entier. Je ne suis pas sûr d'où cette analyse tente même d'arriver, à moins qu'elle ne soit visible: visible en tant que tableau et essayant d'utiliser: name comme index. Je m'excuse à l'avance si cette question est triviale/apparemment absurde/manque d'informations vitales/etc. Des conseils, des suggestions, des liens, ou quoi que ce soit vous seraient très appréciés, même s'ils sont dans le sens de «vous faites cela fondamentalement mal, revenez et faites-le de cette façon».

-Nick

+0

Restez à l'écart de la sérialisation. C'est le premier problème que vous avez, mais vous aurez plus de problèmes à cause de la sérialisation. Ajouter des colonnes spécifiques n'est pas du tout faux. – wanghq

+0

@wanghq: Il n'y a rien de mal avec la sérialisation (si vous cuisinez bien). –

Répondre

6

Rails 3.2 introduit un nice addition to ActiveRecord, qui vous permet de stocker les paramètres arbitraires dans un seul champ.

class User < ActiveRecord::Base 
    store :settings, accessors: [ :color, :homepage ] 
end 

u = User.new(color: 'black', homepage: '37signals.com') 
u.color       # Accessor stored attribute 
u.settings[:country] = 'Denmark' # Any attribute, even if not specified with an accessor 

Ainsi, votre code pourrait ressembler à ceci:

# model 
class User < ActiveRecord::Base 
    store :settings, accessors: [ :name_visible, :email_visible ] 

end 

# view 
<%= f.label :name %> 
<%= f.text_field :name %> 
<%= f.check_box :name_visible %> 
+0

Pensez-vous que cela vaut la peine de mettre à jour mon application de la version 3.1 à la version 3.2 pour cet ajout? Comme il s'agit de ma première application Rails, je ne sais pas à quel point il serait difficile de "mettre à niveau". À moins de me tromper, Rails ne garantit pas la rétrocompatibilité, donc il y a toujours le changement qui dans ma tentative de rendre la vie plus facile dans un sens, je me retrouve avec une foule de nouveaux problèmes. –

+0

3.1 à 3.2 mise à niveau est [absolument indolore] (http://guides.rubyonrails.org/3_2_release_notes.html#upgrading-to-rails-3-2). Vous avez juste à changer quelques versions de gemme dans Gemfile. Aucune raison de ne pas mettre à niveau. –

+0

Okay, donc la mise à niveau était indolore et le modèle mis à jour. Je peux l'éditer dans la console et ça marche plutôt bien. Le seul problème est que le formulaire ne semble pas mettre à jour ces champs. Je n'ai aucune idée de pourquoi c'est; le formulaire met toujours à jour tous les autres champs, mais si vous cochez la case à true, le champ: settings est {}. Des idées? Mise à jour: La définition manuelle de la valeur d'un champ tel que name_visible dans la console entraîne une modification de la forme de la case à cocher, mais la modification de la valeur de la case ne modifie pas la valeur dans la base de données. –

Questions connexes