Rails Mnemonic: Scaffold Actions

Over the last week I’ve been learning how to quickly develop simple applications in Rails without looking at API documentation. Each day I’ve been starting from scratch and seeing what I can create in an hour, only consulting documentation when I really need help. The first day I didn’t use scaffolds and I only got creating, reading, and deleting working with a single model. From the second day until today I’ve been using scaffolds. On Friday I got two models with a has_many association and image attachments (using paperclip) working. Each day I start from scratch, not copying or referencing the code from the previous day (though I do save the code). I think starting from scratch each time has helped me learn more quickly than I would if I were to use the last code each time.

Today I went back to working without scaffolds. Since I’ve been trying to read the documentation as little as possible while developing, I had to figure some things out for myself. One thing I had to think of was the list of actions to type when generating a controller. Here is what I came up with:

script/generate controller Planets index new show edit create update destroy

I’m obsessive-compulsive, so not only did I try to remember what actions are used in scaffolds, I tried to put them in an order that makes sense to me. I put index first because index is special. After that, there were two sensible approaches I could think of to order the remaining actions. I could either order by CRUD or order by whether or not the actions have views. Either way, I would use the other ordering technique within groups. I went with ordering first by whether or not actions have views, and then by CRUD. I started with the actions that have views because it’s nice to have them at the top when jumping from a view to its controller.

Here’s my thought process in a tabular format:

Notice that there are a couple of holes in the table. The first one (*) is missing because the interface for deleting is built into the index. It doesn’t have to be this way, and in fact varies widely on the web. It could have its own page, or it could be on the show or even edit page (Side note: I think it’s bad UI to put the delete button on the edit page because the edit form doesn’t fit into the workflow of deleting an item. The user may want to look at an item before deleting it to make sure it’s something they don’t need, but they’re unlikely to want to edit an item). The second one (**) is missing because in the simple case reading is achieved entirely through GET requests.

One thing that’s convenient about having the ones without views at the end is that it makes it easy for me to remember which skeleton views to delete after running the generate command. It’s the last three.

It used to take me a minute or a few to remember what actions I need, but now that I have this mnemonic it should only take a few seconds.

Now, I place a certain level of importance on conventions. After I came up with this mnemonic I looked at a scaffold to see how rails orders things. The only difference between my ICRUDCRUD ordering (index, CRUD with views, CRUD without) or ICRUCUD ordering and the standard scaffold ordering is that the show and new actions are swapped. So rails uses the RCUD ordering. Fair enough. I have pontificated on whether the ordering in CRUD makes sense or is a bacronym. Create and read are pretty useless without eachother. Below is the table with the RCUD ordering. I threw index into the empty cell. If you read the first line left to right, then move down, like a book, the order is the same as it is in a scaffold:

Now, how to remember RCUD? Well, remembering to swap C and R is one way, but I prefer to think of a Rails cow chewing its CUD.

Original image from cerulean5000 on flickr. Used by Creative Commons license.