You can clone with
HTTPS or Subversion.
Hi there, somewhat new to Rails 3.x, and couldn't find an issue similar to this one (although a similar StackOverflow was asked here) -
I'm running through the RailsCast formtastic vet application tutorials, and have a form which populates checkboxes (f.input :problems, :as => :check_boxes) based on a many-to-many relationship:
class Animal < ActiveRecord::Base
has_many :problems, :through => :symptoms
<%= semantic_form_for @animal do |f| %>
<%= f.inputs do %>
<%= f.input :name, :hint => "Use the owner's name if none is provided" %>
<%= f.input :female, :as => :radio, :label => "Gender", :collection => [["Male", false], ["Female", true]] %>
<%= f.input :problems, :as => :check_boxes %>
<% end %>
<%= f.actions %>
<% end %>
This works flawlessly, but when I change it to "f.input :problems, :as => :radio", it creates the radio inputs properly, and seems to save my selections properly upon database inspection, but when I return to edit an animal, my prior selection is not displayed (in fact no radio button is shown as selected). If I make a new selection, it will be saved, but if I make no selection, it retains my last saved choice. Not sure if I'm missing something with a :collection here, or where to go from here.
@astockwell is this still an issue for you? Closing for now since this is over a month old, but please re-open if it's still an issue for you. Formtastic version would be helpful too!
I found the same issue above. When I edit an instance with ...
<%= f.input :participantmenupriorities, :as => :check_boxes %>
I see check boxes for the has_many through association with the selected associated record checked.
When I change to:
<%= f.input :participantmenupriorities, :as => :radio %>
... the radio buttons are displayed as you would expect but none are checked.
I will play around a bit more but it only seems to happen for has_many through associations.
@tpbyrne @astockwell I've had a look at this finally and we have no spec coverage for RadioInput for any association other than belongs_to. Seeing this caused me to wonder why we don't have coverage, and I think my answer is simply "because it never occurred to me that a radio input would be used for that kind of association".
Radio button sets and single item <select>s are for selecting one item from a collection, which is something I'd model with belongs_to :foo. Checkboxes and multi-selects are for multiple selections, something I'd model with has_many :foos or `has_many :foos, :through => :bags.
So, we possibly make this all work, but I've got to ask… "why?".
What would I do when you want to render a has_many association with two items currently persisted in the database as a radio input? Radio button sets by definition only have one item selected at a time.
If there will only ever be one item selected in your database, then why is it modelled as a has_many or has_many through?
It feels more like the bug here is that we need to raise an error when you try this, not that we need to get better at doing it.
Firstly, Thanks for your response on this.
Hmmm...I see your point.
I think I may indeed have the relationship reversed. I think rather than you considering a change, I should first see if I can use a belongs_to. More anon...
Although I did need a many-to-many relationship between two of my models I lazily implemented a similar relationship when I really needed belongs_to and has_many between two other models.
I can't think of any strong reason to allow radio controls on a has_many relationship and you make a strong case not to.
The radio inputs display correctly and work (in terms of selection) with a has_many so the only thing you might consider is some text in your documentation to warn fools like me :)
Thanks again for your support and for a great gem.