Rails - Day 4 - Rails Generators

Rails  - Day 1 - The RubyGem Love Story

Rails  - Day 2 - The Power of Consistency
Rails -  Day 3 - Rails environments

Rails -  Day 4 - Rails Generators

Rails  - Day 5 - Rails Migrations

Rails  - Day 6 - Blueprint, Compass, SASS and HAML
Rails -  Day 7 - Our first View
Rails -  Day 8 - Down and Dirty with HAML and SASS
Rails -  Day 9 - Rendering Content

Rails -  Day 10 - Testing Rails Controllers

Rails -  Day 11 - Model Testing and 101 ActiveRecor

Rails -  Day 12 -ActiveRecord Relationships Part I

Rails -  Day 13 -ActiveRecord Relationships Part II

Rails -  Day 14 - Rails Forms Part I

Rails - Day 15 - Rails Forms Part II

Rails - Day 16 - Validation

Rails - Day 17 - Update and Delete

In my last post, I illustrated how a guaranteed folder structure allows a lot of magic in Rails to flow.  This magic is called convention over configuration and allows us to free ourselves from the shackles of external xml configuration files.

Generators in rails are probably the first thing that really got me salivating for more rails.  Generators are what made me stand back and think, hold on a second, these guys might just be onto something here.

In .NET the workflow commands are executed via the IDE, generally in the form of the Add File menu option.  Let us break down that previous statement.  I am more often that not adding a single file as a .NET workflow command.  This statement is in itself limiting.  The only way I can generally add a group files is in the form of a Visual Studio project.  Not very exciting or more importantly not very productive.  

There are and have been many code generators in many platforms that I have used and a couple, I have wrote myself but as I am sure you have experienced, they very rarely cut it.  A Rails generator is as you might have guessed, is a unit of such code generation.  So why is this better than the various approaches that I have just lambasted?

The rails generators are better because they are not trying to generate a whole project from a database or anything big time like that.  They are an important part of the workflow that allows Rails to push and prod you into doing the right thing or going down the right path.  It is these little nuggets of ingenuity that make it difficult for the developer to do the wrong thing.  This is yet another example of Rails exerting its pushy and if I did not know better, I would assume is a somewhat Irish personality.

Another feature of rails I want to illustrate with this post on generators is the often overlooked help available in rails.  The request for help is issued through the command line and not via the search box of the google home page, so this again is a switch of thinking.  Let us see what help is available on generators.  We simply type ruby script/generate and after a fairly lengthy wait that I find hard figuring out why, we are greeted with the following text:

This help text shows us all of the options and generators that are currently available.  We are going to concentrate on the resource generator for this post but a good exercise for the reader is to check out the other generators on this list.  Certainly cucumber seems to be one of the current ALT.NET darlings that I am less convinced about but you can generate a lot of your cucumber boilerplate code from here.

Here is a list of generators available from the rubyonrails wiki.

Not only do we get help on generators as a whole but we can also further drill down and get help on specific generators.  As previously mentioned, we are going to look at the resource generator.  To get help on this, we simply type ruby script/generate resource.  We are then presented with the following:

As you can see from the above, there is a more than adequate explanation and contains the usual list of switches and options available.

What the above text is basically saying is that rails is going to create all the files necessary for us to work with what we are stating here is a resource.  Rails is using resource in the context of a REST  resource.  You can think of resources as the nouns in your application.  Typical examples are User, Customer, Order, Role etc.  

Resources are an abstraction we are going to perform operations against.   In strict REST terms, these actions are CRUD actions, Create, Read, Update and Delete.  I am not a REST zealot or RESTifarian or whatever the hell they are called, so the last sentence might be incorrect.  

The resource we are going to create for our simple, semi-mythical application is a User.

In order to generate our resource cruft , we issue the following command ruby script/gnerate resource User user_name:string, password:string, full_name:string. It should be noted that I am adding some initial fields to the User resource that will be added to our model after the  ruby script/gnerate resource User statement. We get the following confirmation screen of what rails has generated:

So let us look at what Rails has created for us.

1. A new helpers module in app/helpers/users_helpers.rb.  This again is great because all our helpers will be consistently named and consistently located.
2. A new class definition of our user model class in app/models/user.rb.
3. A new controller in app/controllers/users_controller.rb.
4. A unit test has been created for us in test/unit/user_test.rb.  The message from Rails is clear, write tests now!  Even if we are not currently doing TDD, our concience is being prodded by the creation of this file.  A helper class in test/unit/helpers/users_helper_test.rb has also kindly been added if we need a helper for our tests.
   
   

This generation of consistently named files makes me feel good and clean about the world in general.

Rails has also updated our config/routes.rb file to add an entry for users.

I hope you can see the contrast in productivity between the Add File paradigm of Visual Studio and the resource generation of a Rails application.

It is also worth noting that the resource generator does not create any views for us.  It does create a folder in app/views/users but it does not create a view.  There is a scaffold generator that will do that for you but I am not a huge fan of scaffolding.

Let us be perfectly clear here, there is nothing a generator can do that you cannot do yourself.  They just take the tedium out of some common Rails tasks that you'd otherwise do by hand.

It is worth noting that what we can generate, we can also equally destroy.  There is a script/destroy script that will so the dirty deed for us.

Another file that the generator script has generated for us will form the subject of my next post.  It is cryptically named db/migrate/20100307123141_create_users.rb.

This brings us onto the concept of Rails migrations.  Stay tuned for our next thrilling instalment that will explain the concept.