Even though Rails makes it easy to make changes to your application, it’s still helpful to do some upfront planning. Thinking about what your application is going to do and what types of information it will handle can help you plan out what types of features your application will need, and even help you understand potential areas where you’re likely to run into trouble building it, especially if you’re just learning Rails for the first time.
Just use the back of an envelope
More formal software settings (i.e., big companies) might use a UML software modeling tool to create class diagrams and generate formal software requirements. Since we’re just building a simple application for demonstration purposes, I’m going to use an informal page flow diagram along with a feature list to give you a sense of how the application will be laid out.
Presenting the Page Flow Diagram
Users
Our application will need some users. The obvious data fields associated with a user will be a name, email, and a password so the user can log in.
Folders
We want the ability to be able to associate tasks with certain projects, or folders. The idea is a “folder” can contain tasks specifically associated with it. The obvious data field associated with a folder will be a name.
Tasks
The diagram shows the data fields associated with a task would be a description and due date.
1…n?
What about this strange notation 1…n? This is a shorthand notation borrowed from database design principles. It’s a notation used in the book Agile Web Development with Rails. It denotes a “one-to-many” relationship. In other, one user can have many folders and one folder can have many tasks.
What about the term polymorphic?
In rails, a polymorphic association allows a model to belong more than one model on a single association2. What does that mean in the context of our application? Essentially doing this allows us to associate our “task object” with both users and folders. It allows us to grant a user the ability to create a task but not associate it with a specific folder. Polymorphic associations are a good way to go when each model requires a lot of distinct database columns. In our specific case, a user model needs a name, email, and password database column whereas a folder model needs a name column.
Now we could have not specified a polymorphic association and just used a has_many/belongs_to relationship between both users and tasks and folders and tasks, but doing so would have meant we had to have 2 foreign keys in the tasks database table — one to refer to users and one to refer to folders so that a task would know who its parent is. If we should ever want to add another model object that can create a task, then we would need a third foreign key. This could potentially become unwieldy or at least mildly painful to do down the road.
I’ll admit, that for the purposes of this tutorial, this might be a fairly contrived use case for invoking polymorphism. But it is a feature of Rails worth exploring and playing around with, and that is the point of any good tutorial – to expose you to new concepts and help you learn them. If you’re a beginner to the Rails framework, I would say this topic will become more comprehensible once you start building more Rails applications. For the purposes of this tutorial, just follow along as best you can, and if you have any questions, please feel free to leave a comment below.
Feature List
We want to think about what features our application should have and keep that in mind as we’re building it. So what features are we going to tackle? We’ll start with a handful of features to keep things manageable. We want to be able to:
- Sort tasks by due date and by name
- Create/edit/delete a task description(s) and due date(s)
- Create/edit/delete a folder
- *Tweet a link to our task descriptions
- *Reorder our folders via a drag and drop interface of some kind
I’ve used an asterisk next to tasks 4 and 5 because those aren’t critical tasks (at least for the purposes of our exercise). These are more like “challenge” or optional problems to be solved during the later stages of this tutorial.
Summary
Now that we’ve done some upfront planning for our application, it’s time to dive in and start building it.
Resources:
I’m keeping a public repo of this application at my github account. You can download the source code there.