This Nested resource CRUD tutorial does a great job of quickly explaining how to get a nested resource working in a RESTful Rails application. If you want some more detail, this RESTful Rails Development PDF covers more while still remaining succinct. It is worth a read, even for non-rails developers, since it explains more about how REST works. Especially helpful is the explanation of how the HTTP verbs are used to call different actions in the controller.

Learn from my mistake and don’t forget to modify the nested controller’s create action. This is noted in the PDF but not the post. Left unmodified, the create action will insert the nested records (in this case, “comments”) with NULL foreign keys in the database.

There are a couple ways to fix this. I’ll keep with the posts/comments example in the code snippets below. The method used in the PDF simply adds one line of code to explicitly set the parent id as shown in bold below:

def create
	@comment = Comment.new(params[:comment])
	@comment.post_id = @post.id
	. . . .
end

The other way, which I prefer, is to replace the call to the comment’s new method with a call to the build method as shown in the following code:

def create
	@comment = @post.comments.build(params[:comment])
	. . . .
end

This accomplishes the same thing in one line rather than two, therefore, I like it. Thanks to Ryan for pointing this out on railsforum.

Writing code without using version control is the equivalent of swinging on a trapeze without a net. Sure, if you execute each move flawlessly, you’ll be fine. But, one wrong move and you’ll fall to your death. Okay, coding mistakes rarely lead to injury or death–of the programmer anyway–but I think you see my point.

There are loads of version control systems out there. Subversion, however, is the weapon of choice for most people working with Ruby on Rails. If you are unfamiliar with Subversion, the Subversion book is a good place to start (print version available on Amazon). The first part of this book gives a good overview of what version control is all about, so those totally unfamiliar with the concept can jump right in.

As for Ruby on Rails applications, they can just be checked into version control like anything else. But, there some files and directories that don’t really need to be under version control. There is an easy, step-by-step guide on using Subversion with Rails at the Rails wiki. Following these instructions takes less than five minutes and will keep your repository free of extraneous files (e.g. log and temp files).

With your Rails application under version control, you can rest easy knowing that you have some recourse when your latest code update breaks everything. Just don’t forget to commit your changes on a regular basis or this is all for naught. Also, remember that the Rails generator scripts accept an --svn option which will automatically add generated files to your repository. This will save you the step of adding these files manually later on.

In addition to giving you a sort of coder’s safety net, using Subversion gives you the ability to automate application deployment with Capistrano if you wish. So, now you have two excellent reasons to get your application into Subversion. By the way, if you are looking for a place to store your repository, check out CVSDude. They offer several monthly plans, including a free one.

Rails Envy has a great screencast tutorial on ActiveRecord. Gregg does a great job explaining a couple concepts that can be difficult to grasp like has many :through and polymorphic relationships. This is well worth watching for anyone new to Ruby and Rails. Even if you are not working with Ruby, it is a good way to see how Object-relational Mapping is achieved in Ruby with ActiveRecord.

via Ruby Inside