A while back I started writing a post about web application design and it got too big and weird for a single post or even introducing what I wanted to say. So I’m going to start with something short, simple, and obvious: what you get using a Rails scaffold.

Ruby on Rails has a pretty good generator system and that includes a couple “scaffold” generators which are helpful to illustrate, if not automate, “the Rails way” of developing a basic CRUD interface.

If you run:

rails generate scaffold wat name:string

A bunch of things will get setup in the application to support the new model and interface. After a little more set up you can run the Rails app, visit /wats and start creating Wat objects.

Here’s a table based on the one in the rails routes for this example resource:

HTTP method resource path controller action
GET /wats WatsController#index
GET /wats/new WatsController#new
GET /wats/{id} WatsController#show
GET /wats/{id}/edit WatsController#edit
POST /wats WatsController#create
PUT/PATCH /wats/{id} WatsController#update
DELETE /wats/{id} WatsController#destroy

That’s worth looking at closely, but what I’m sharing today is a diagram I made of the links and actions of the scaffold generated views. The idea is to show the workflow that’s created by the scaffolding.

WatsController#destroyredirect_to indexWatsController#createredirect_to showWatsController#updateredirect_to showshowbacknewbackeditbackdestroyindexcreateshowupdateshowshowedit

In the diagram are wireframes of the views with arrows for links and actions take you, and giving a sense of the basic workflow.

Here’s an abstraction of the same, distilling the interface to an essential structure:

wats_flow index index index->index destroy new new index->new show show index->show edit edit index->edit new:s->show:w create show->edit edit:s->show:e update

Having worked in Rails for a goodly while now, and having stared at this setup and it’s underlying code a lot, and having been required to build new features, fix old bugs on many things built this way. I’ve come to have some opinions of my own about things. If a picture is worth a thousand words, then I’m hoping the table and diagrams will give the mind some things to pattern match on and ask questions about.

Here’s some thoughts and questions I’ve had to puzzle over which I hope to explore in future posts in this series:

  1. Starting from the index the flow has two short paths into the “update” cycle. What alternative paths could be made? What ways are there out of the update cycle?
  2. Over time, the wats table fills up with entries. How can we setup searching and sorting features? What about aggregates and archives?
  3. If we need more specialized interfaces and actions, to support complex processes, how can we find “natural” ways of extending the structure we find here?

For the next post I want to explore the questions what ways are there to add a feature for copying Wat entries, and how do we choose between implementations?