Updates to Related_Selects plugin

Two weeks ago, Corey Ehmke sent a pull request for some updates he made to the related_selects plugin on GitHub. Im actually quite late in pulling these but I have been extremely busy with work and family stuff. Here is what Corey said about the changes:

I made a couple of changes that you will hopefully incorporate:

1) Expanded support for include_blank to match behaviour of standard Rails form options helper. You can now pass an :include_blank attribute consisting of true, false (default), a string, or a two-element array, just like the standard Rails select form helper. If you do not set this attribute, the related select will default to the first option.

2) I also edited the README and replaced the original examples with the (much more concise and comprehensible) example from your post on angry-fly.com.

This is great! Thanks again for the updates Corey!

Related_Select plugin update for Rails 2.3

Last night I was looking for a solution that would allow me to easily create a setup of related select boxes. I needed 3 of them to be exact. You know the ones that always seem to pop-up from time to time where the contents of one select box are populated after selecting a value on the first select box.
I started googling for a solution and came across a Rails plugin called related_select_forms that was written by Dimitrij Denissenko back in 2007. I figured “what the heck” it looks easy enough. Well after installing it from the svn repo on google code and setting up my initial form fields, I was welcomed by a plethora of errors. So I started digging into the plugin to find the issues and ended up fixing everything so that it now works with Rails 2.3.2.
I sent an email to Dimitrij asking about the status of the plugin but I havent heard back from him as of yet. I created a GitHub repo for the plugin to allow me to share my fixes with everyone. It can be found here:
Let me take just a second to show you how easy it was for me to create 3 related select boxes in my form with this plugin.
Consider the following models:

class Metro < ActiveRecord::Base

   has_many :areas


class Area < ActiveRecord::Base

   belongs_to :metro

   has_many :neighborhoods


class Neighborhood < ActiveRecord::Base
   belongs_to :area

Just looking at the models it should be plain to see how the selects should be related. You must first select a Metro, then that will populate the Areas. Once you select the area, that will populate the Neighborhoods.
Normally this would take a lot of handwritten Javascript to accomplish. And I know there are probably some super simple jQuery plugins for this thing, but this application is using the standard Prototype/Scriptaculous combo that ships with Rails.
So here is the how simple the form fields are using the plugin.

<%= f.label :metro_id, ', :class => 'title' %>
<%= f.collection_select :metro_id, Metro.find(:all, :order => "name"), :id, :name, :include_blank => true %>

<%= f.label :area_id, ', :class => 'title' %>
<%= related_collection_select(:sales_contact, :area_id, [:sales_contact_metro, :id], Area.find(:all,:order => "area" ), :id, :area, :metro_id) %>

<%= f.label :neighborhood_id, ', :class => "title" %>
<%= related_collection_select(:sales_contact, :neighborhood_id, [:sales_contact_area, :id], Neighborhood.find(:all,:order => "title"), :id, :title, :area_id) %>

Notice the first select is a standard collection_select then for each related field. We make calls to the plugin. The method signature is very similar to the standard collection_select with the addition of a couple parent related arguments.
Super simple!
If you have any improvements or additions, feel free to fork the repo and send me a pull request.

Deployment Gotchas – Git And Capistrano

Im just starting to take the leap with Capistrano and so far Im loving it. It simplifies deployment task down to a single command-line call. In my book, that beats syncing the FTP, manually running migrations, etc. One issue I ran into last night though, was during my deployment, I clone my git repository to get the latest version of the application. Thats baked into Capistrano, very simple stuff. However, I kept getting an error that ‘git-index-pack‘ was not a git command.
I spent literally hours googling, reading mailing-list archives, tweaking, updating git, reinstaliing git, etc. Nothing I did made one bit of difference. Being up until 5am probably didnt help me to think clearly either. So after a few hours sleep, I started investigating again. This time it hit me. It hit me like an Amtrak train at full speed.
I host on my own dedicated servers, with that being the case, I have my CentOS servers setup to use Jail-Shell by default for all new accounts in the web group. I completely forgot to change the shell for my deployment user so of course git was failing! Doh!
As soon as I changed the default shell for that user to bash and ran ‘cap deploy:update‘ it worked like a charm!
So if you are deploying to a shared host and running into this issue, make sure to check your shell. I know there are hosts out there that will Jail-Shell you by default.

Forms With Nested Resources In Rails

This post is more of an informational post for myself in case I forget this later on. I have been working on a client project thats using Ruby on Rails and I was having a little trouble getting my head around nested resources and the routing that goes along with that. Once I had the routing figured out, the next thing to address was handling my forms. Now, as with all things in programming, there is more than one way to “skin a cat” when it comes to this in Rails but for the most part, this is from what I can tell, the preferred method and I like it better than the alternative.
To start off with, nested resources is simply a way to have much cleaner urls without having to append a query string to the url. So you can have something like:


instead of:


Of course the nice URL’s are not the only reason for doing this. When it comes to handling forms, Rails can handle all of the associations for you reducing the amount of code you are writing.
So, borrowing form the earlier example of products and categories, we can easily setup our form to handle the relationship by modifying our form_for arguments in the form like this:
form_for [@category, @product] do |f|
Now we no longer have to manually add a hidden field containing the category id.
In our controller, several methods are affected by this change, but lucky for us the changes are simple.
First, lets look at the new method which sets up the blank form:

def new
@category = Category.find_by_id(params[:user_id])
@product = @category.build_product
respond_to do |format|

Since we are referencing the product through the category, its best to use the category itself to build the new product object. This allows the previous change that we made to the form to work. Now lets have a look at the create method that will actually save our form:

def create
@category = Category.find_by_id(params[:user_id])
@product = @category.build_product(params[:product])
respond_to do |format|
if @product.save
flash[:notice] = 'Product was successfully created.'
format.html { redirect_to edit_category_product_path(@category,@product) }
format.html { render :action => "new" }

Notice again that we are building the product object through the category association and passing the product data to it from the form to populate it. Thats pretty much all of the magic sauce. There is one other thing to notice in that method that warrants attention. Notice the redirect_to method? Normally that would look something like this:

redirect_to edit_product_path(@product)

But since we are accessing products as a nested resource of categories, we simply add in the category part to the method and supply the category instance variable to the argument list. This will ensure we are redirected to the proper url.
Now I know this is a dumbed down version of this, but hey, like I said earlier, its more for my reference later on. Hopefully someone can get something out of it as well.

See if your Twitter friends follow you back

My buddies over at Less Everything have struck yet again! I seriously dont know where these guys find the time to build these apps and do client work. They must have an attic full of little Rails coding squirrels cranking this stuff out for them for the small price of a few acorns a day.

This time they have released LessFriends. A neat little app that allows you to see the following status of you and your friends on Twitter. It shows all of your friends and tells you if they follow you back or not. Pretty neat.
I was amazed at how many people do follow me back when I ran it the first time.
Im still not sure if there is a real benefit to the app other than just using it to help you do a little house cleaning on your friends list but that in itself could prove useful.
Another nicely designed app, go take a look if you use Twitter.

New Ruby on Rails Article on Apple Dev Site

I was up REALLY late last night doing some coding and I received an email from the Apple Developer site saying that they have added some new articles. In particular, the first one listed was a new Ruby on Rails walk-through that has been updated for Rails 2.0 and Leopard.
They show examples of coding a Rails app in Xcode which I thought was pretty cool. I have never used Xcode before but Im definitely going to at least open it and give it a whirl now after reading the article.
My hats off to Apple, a very good read!
You can find the article on the Apple Dev site.