collection_select *THIS*

27 Feb

Spent a good 3 hours today trying to get a simple (?) select box working in a create form. The create form is for ‘pages’ (from the ‘simple_cms’ app developed in the tutorial on Lynda.com) while the select bax needed to display a list of choices from another class. I was hiking on my own here, well of the tutorial map, dressing things up and trying to implement something a little more helpful and interesting.

The code, now that I’ve got it working, is now woefully unassuming:

<tr>
        <th>Subject</th>
        <td><%= collection_select(:page, :subject_id, Subject.all, :id, :name) %></td>
      </tr>

Just some HTML and a bit of embedded Ruby. Certainly nothing to keep a man hunched over his laptop for several hours, right?

I wish!

Where you now see ‘:subject_id’ (so clean and simple) I previously had ‘:id’. That was my first and biggest problem, from which all others henceforth cascaded, in an unrelenting, repentent-less (can I say that?) flow. (I said it.) The Subject object id’s would appear very nicely in the drop-down (by their :name attribute, no less) but never got written to the database and I couldn’t figure out why. So I went a-Googling and a-trying some other helper methods and a-beating various bushes and getting…results, but none of the results I wanted.

Oh, and errors. Lot’s and lot’s of errors, too. Mustn’t forget those.

Then, to make things more confusing, the new data with the missing id caused the ‘list’ view to break which alone took me a fair while to figure out. (see ‘errors’ above)

By the time I did, I was getting pretty good with command-line MySQL. I was also getting pretty good at pulling out fistfulls of my own hair, which is perhaps slightly less valuable on today’s job market. This tutorial uses MySQL, which is kind of cool. SQLite3 is much easier to get going with, but the experience I’ve gained using MySQL this time is much more extensive.

So anyways, that pesky ‘:subject_id’ field was the culprit. ‘subject id’ is the foreign key in the ‘pages’ table I really (and I mean REALLY) wanted to populate. For a long time the drop-down seemed to be working and showing all the desired choice options, but after submitting the form, the relevant field in the database was always, constantly, confoundingly and steadfastly, ruthlessly and forever deeply, cunningly and unforgivably an endlessly echoing cavern of relentless emptiness. (Did I already use ‘relentless’?) Anyways, the Dalai Lama would have been very proud of the formlessness my subject_id’s were displaying.

Thing is, I was calling it by it’s foreign name, ‘:id’ instead of the key name, ‘subject_id’.

Oops. Is that a problem?

And so it was actually working fine the whole time, doing exactly what I was telling it to. Updating the pages.id and not even glancing at the pages.subject_id.

Do you hate that? I know I sure do.

Pick through the rubble at GitHub.

Also, big thanks to the StackOverflow poster who provided this lovely (and I do mean lovely) human-readable-run-down of the ‘collection_select’ helper.

Advertisements

Comments are welcome!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: