In the last entry of my Rails 3 series, we started looking at how you would implement a typical CRUD controller in Rails, but we really only explored how you would display the data from the controller. We also took a look at how you would route requests to that controller, and also how you might do some simple testing with RSpec. In this part of my Rails 3 series, we are going to take a look at the "UD" part of the CRUD controller; the update and delete actions.
In this post we are going to take a look at a typical CRUD controller in Rails. We will use a modified version of the controller generated by the command that we can in Part 3:
rails g scaffold Baby name:string age:integer
If we remember, this generated a ton of stuff for us (which can be good and bad), one of which was a controller called BabiesController. If you look in the controller you’ll see that a bunch of actions are in there. These actions were generated with important names, and one way to see that is by looking in our routes.rb file. In this file we will see that our entire controller is being wired up by one line:
So here we see what Rails calls a "resource route". It is a route which supports a common set of actions to support RESTful controllers. The standard actions supported are these:
- index – Shows a list of all saved models.
- show – Display a single read-only view of a model.
- new – Renders a form to create a new model.
- edit – Finds a model, then renders a form to edit it.
- create – Where a new model is posted to be saved.
- update – Where the edit form posts to be saved.
- destroy – Deletes a model.
If you can, it is a good idea to use the resource routes and stick with the default naming. It’ll save a ton of typing and make thing more predictable. And don’t think that it’ll lock you down, the resource routes are completely configurable. You can add in custom routes and opt out of specific routes.
In the last entry in my Rails 3 series we looked at hooking up a Controller and View so that we could render a page in the browser. By doing this we technically had a working Rails app, but we were missing one piece of the MVC puzzle, the model! In order to really connect the dots, we need all three pieces in place.
But before we go there, I want to hook up one more piece in our Rails 3 application…RSpec. You have probably heard in the past just how crazy Rails developers are about testing. Well, everything you have heard is true. Not only is testing a very good thing, but testing in languages that are as dynamic and flexible as Ruby are absolutely critical. While I am certainly not a TDD wizard by any measure, I do enjoy a nicely written, tested codebase.
Because in Rails we sometimes like to generate code, I would like to go ahead and get RSpec pulled in and wired up so that when we start to create our model and controllers, we get some example test code along with it.
In the last part of my series on Rails 3, we got up and going with Ruby, RubyGems, RVM, and finally Rails. It may have seemed like a lot of overhead to get up and running, but keep in mind that RVM only needs to be setup once on your machine, then you can use it on as many projects as you would like.
In this part I want to create a single static vertical stripe in the application. We are going to do this by creating a route which will map to the root of our website. We are then going to use the rails executable to generate a controller and some views to go with our route. In this post we are going to focus entirely on getting the entire pipeline running, but without a database at this point.
If you’ve used Rails before, then you probably know that it is big on convention. Everything has a default place, and the project structure is no exception. If you were to open up your project folder, you’ll see this:
Sure is a lot of directories! For now, let’s just focus on three of these folders:
As you may have seen from many of my past blog posts, I’m a big fan of Ruby. I’ve been a web developer for a long time now, but for the most part I’ve been working solely within the Microsoft .NET world. Over the past few years I’ve been working with ASP.NET MVC heavily for my day to day work, and I love ASP.NET MVC. It is a great framework. However I’ve had my eye on Rails for a long long time, and I even spent a solid chunk of time a few years ago going through “Agile Web Development with Rails” (that is an updated Rails 3 version), but never got into the world of Rails development since my day to day job was on the .NET stack.
Ever since then I’ve been itching to wade back into those waters. Over the past few months I’ve been doing just that, trying to spend some of my free time delving deeper into Rails 3 than I have with any other version. I didn’t want to just slap together a Rails app and say “Done!”, I really wanted to understand the ecosystem and the day-to-day tools that a “real” Rails developer would be using.
Coming into an already mature ecosystem can be a daunting task. Usually the hardest part of it all is trying to filter out the chaff so that you can get to the wheat. If you aren’t familiar with a development ecosystem, you don’t have a good sense for what is needed and what isn’t. You can quickly become overloaded with the minutiae and fail to learn anything. It requires someone with knowledge and time to wade through it and provide you with some guidance.
The problem is, most of the experienced people aren’t interested in blogging about the beginner stuff anymore, they’ve been doing all of this for years, they want to get to the new features and the more advanced stuff that is useful and interesting to them. I hope to help remedy that a little bit with this series.
Over the last few weeks I’ve been digging into Rails 3 in the hopes of getting a grasp on the tools and environment. I’ve avoided blogging about it up until now, but mostly because I didn’t feel like I could be a respective voice on the topic. I’ve had a number of people encourage me to suck it up and just put something out there. So here it goes…