Continuing with Rails

In my blog post on Rails "12 Lines of Code" I showed an overview of a *simple* rails application. OK, application might be a little strong, it was just a step or two ahead of a "Hello World"

One of the questions I had when I started looking at Rails was, how quickly does this run out of steam? Last year a I looked at some Java-based Rails-like tools. Frankly, I wasn’t impressed. It feels like Java has gotten so complex as it has grown into the tool for everything that it is too heavy for some uses.

So, let’s see what happens when we make a few changes to our application. How much re-work is required? What is the cycle time? What is the complexity?

Something that every DB-backed app has is data in multiple tables with relations between the tables expressed in one or more ways. Usually with Foreign Keys in the DB, in application logic, and ultimately in the user interface. A simple extension to our application would be to add a table of "meeting categories" that we can use to classify the type of meeting. We’ll repeat the process (eventually) to allow us to have a list of meeting atendees, a list of agenda items and discussions, and perhaps action items for folks at the meeting. Let’s get to it!

From the command line:

Much like before, we generate a controller and a model. Let’s edit the just-created migration for our category model in 002_create_categories.rb:

Edit 001_create_meetings.rb to add an id column to our table definition:

Now open the two models category.rb and meeting.rb. We need to tell Rails that there is a relationship between these two tables.

category.rb

meeting.rb

The takes care of the plumbing. What we did, in review, was:

• Generate a new model (including a migration) and a new controller
• Set up one column in the migration for the new model
• Add one column to the meeting model
• Define the relationship between the two models

The has_many and belongs_to methods are just two of several Rails methods for specifying relationships. There are others for many-to-many relationships, trees, lists and more. There are options to modify the default behavior, for instance adding cascading deletes automatically. We have just a few more details to take care of and we’ll be ready to try out our new zoomy app.

Notice above that we created a controller for our Category. This isn’t, strictly speaking, necessary. It just gives us a convenient place to plunk in our scaffolding for the new table — which will let us quickly add a few categories for testing. Let’s go ahead and add the scaffolding to category_controller.rb:

Why don’t we stop here and check our work? If all goes well we should have CRUD views for our new category model. The meeting views should be unchanged — Rails is smart enough to know that the new column on meetings is part of a relationship, but not smart enough to know what we want to do with it in the view. From the command line we’ll re-create our database tables from ground zero, start the server and take a look. We’re re-creating the tables from zero by migrating the database to version 0, then running all of the migrations to bring it current. We’re doing this because we changed an already-applied migration. An alternate would have been to add the column through our newly-created migration. I’ve decided that I want to keep the table definitions together until I get to a release point. Subsequent changes to tables for the next release will be done via incremental migrations.

The first migrate rolls the schema back to version 0, the second rolls it forward to the latest migration we have. A quick look at the create meeting form show that it is unchanged, and that we have the basic CRUD views for categories. Lets create a few categories, then go fix the views for the meeting.

So far, so good. We’re up to 21 lines of code. We’re going to stray from the land of dynamic scaffolding now and build a custom view. This will require adding a method in the controller for each view, and then creating a template file to actually render the view. Templates can be done as .rhtml (Ruby scripting to generate HTML), .rxml (Ruby scripting to generate XML) and .rjs (Ruby scripting to generate Ajax/Javascript). For this example we’re going to use the .rhtml flavor.

In app/views/meetingminutes create list.rhtml

OK, what is going on here? As you can probably guess, this iterates over something called @meetings and creates a table of meeting listings. Note that the meeting "knows" how to go look up the category name already! The link_to is a Rails helper method that will (in this case) show the meeting name and create a link to the "show" view. Where does the @meetings thingie come from? That is the controller’s job. The controller prepares the data for the view, like this:

OK, let’s check our work so far. We added a view called "list", which replaces the dynamic scaffolding "list". We added a "list" method to the controller to initialize the @meetings object. Let’s take a look at our work, if you still have the server running just browse to /meetingminutes/list, if the server isn’t running just start it.

That works, but we don’t have any meetings. Clicking the "create new meeting" link takes us to the "new" view generated by the dynamic scaffolding. Let’s go ahead and replace that now. We’ll need to add "new" and "create" methods to the controller first.

The new method creates a new instance of Meeting. The create method gets the data back from the view and tries to save it. At first glance it might look like we’re creating two meetings. Well, actually, we are. Only one actually gets saved to the database. The object created in new is used to initialize the form, the create method grabs the meeting back from the parameter stream, creates a new meeting object and saves it to the database. We still need a "new" view. It should look like this:

You can see that there is a lot of heavy lifting being done by Rails for us here. There are helper methods to create the form and the fields in the form. Rails takes care of passing the data back as a hash, and disecting it to sonctruct a new object. The call to form.collection_select is pretty cool, it creates the combo box, populates it and pre-selects the category if one is selected. That’s handy, because next time we’re going to refactor the body of this form into a Rails partial (partial view) that can be used for both creating new meetings and editing existing meetings. For now, here is our create form:

Notice that the create form has our combo box, and the list view has the category name pulled through the relationship. We’re still not into rocket science, but we have two database tables created, relationships between the tables, schema versioning, CRUD forms for both tables including hand built "list" and "new" forms that utilizes the relationship and we’re up to a whopping 37 lines of code.

We have only begun to take advantage of Rails. For example, adding field validation is trivial, it is just a few helper method calls in the model. We need to look at a few more areas of Rails to really begin to appreciate its power. Stay tuned!

Share This | Email this page to a friend

Server Response from: dnrh1.codegear.com