When coding, there are few things more satisfying than using the command line alone to produce the scaffolding for a new project. Ruby on Rails allows just that through the use of Rails Generators. The Flatiron course introduced some basic Rails generators to create, edit, and destroy models, controllers, and migration files for a given project, but my personal favorite is their introduction of the “resource generator”. Since my initial introduction to generators, I’ve come to find that much of what I’ve learned how to write “under the hood”, can be simply created by adhering to basic nomenclature rules and writing a simple line of logical syntax.
In terms of the Model-View-Controller workflow, I’ve now used generators to produce, edit and eliminate my files throughout my most recent project. In particular, the basic model generator will produce a model and migration file. The controller generator will generate a controller file, a migration generator will open a new migration, and the resource generator (my favorite), will generate one of everything necessary to start up your MVC workflow (model, controller, migration, views, directory, and optionally–routes).
It’s important to remember that file names for models are always referred to and written as singular nouns, and controller file names are always written as plural nouns. After keeping in mind the naming conventions, the syntax is simple: $ rails g <generator type> <name of file> <options> and will produce all the basic and relevant files for my application quickly and RESTfully.
As an example, if I wanted to create a grocery list application that organized food by category and price, I would likely want the application to accept data for foods and have categories and prices as columns. I would jump into the CLI and type: $ rails g model food name category amount:integer{10} price:decimal{5,2} which will give me my food model. In the options portion of the syntax, I’ve included the attributes of my food which include its name, category, amount, and price.
Attributes that are not specifically assigned a type (i.e., “:integer” as a type) are automatically assumed to be a string type. Options for column types are as follows: :primary_key, :string, :text, :integer, :float, :decimal, :datetime, :timestamp, :time, :date, :binary, :boolean, and note that there are multiple other options to add to a given generator.
In the previous example, an optional modifier was added to the price attribute so that the limits of acceptable data are defined as: numerical data with 5 significant digits with 2 digits behind the decimal. Also, the optional modifier written for the food attribute “amount” is set to a limit of 10 items. Modifiers are written in curly braces after the data type and can specify the limits of the data that the application will store in the database. Additionally, flags can be added at the end of generators in the command line to specify which parts of that command are or aren’t executed.
Some useful, pre-written, basic generators for the given example above are written here to provide examples of the utility of generators:
Say in our above example we want the grocery list application to include data for the individual user, the food on the shopping list itself, and the grocery store… since we’ve already created a database for our food list, we can now create a table for nearby stores, which would, necessarily be a join table–to join users to foods through grocery stores.
Creating a database for grocery stores:
$ rails g migration CreateJoinTableStores user address distance:integer open:boolean
Adding a column to an existing table
$ rails g migration AddHoursToStores
This generator, with the syntax “Add…To[tablename]” will automatically produce a migration that includes “add_column” to the text in the migration’s change method and allow us to easily go on our way updating the Stores table.
Similarly, to alter or remove a column (irreversible [can’t roll-back] commands) for a given table, we can specify what text goes in the migration’s change method of the new migration by using “Change…In[tablename]” or “Remove…From[tablename]” as part of the file name in the command line:
$ rails g migration ChangeDistanceInStores
vs
$ rails g migration RemoveHoursFromStores
While the creation of this fake application for the purpose of demonstrating basic generators is not exhaustive or even complete–the idea that I hope to relay is that it is easy to see the utility and power of generators as fast scaffolds for creating, eliminating and/or editing files. After looking into it a bit I found that not only can you create customized generators for your own unique purpose, you can actually generate your own generator using a generator. It is one of the reasons Rails is so comfortable to use when you’re new to coding, and something that I won’t take for granted when I tap into other languages.
Top comments (0)