Goal
Before writing any code for a real Rails feature, you’ll practice planning its models, routes, and controller actions in plain language first, directly applying the MVC thinking from across this entire course.
Learn
Jumping straight into generating controllers and routes without planning is exactly how a Rails app’s structure becomes tangled. A genuine planning pass means answering: what are the actual models and their associations (Part 2)? Do any relationships need nesting (Part 4.3), or are they better as independent top-level resources? Which of the seven standard RESTful actions (Part 3.1) does each resource genuinely need, versus needing custom, non-standard actions? What data needs validating (Part 2.3) before it’s ever considered genuinely valid?
For example, planning a simple blog feature might identify: a Post model with a title and body, a Comment model belonging to Post (nested, since comments genuinely don’t exist independently of a post), presence validations on both title and comment body, and standard RESTful routes for posts (all seven actions) but only index/create/destroy for comments (skipping edit/update if comments genuinely aren’t meant to be editable after posting, only creatable and deletable).
This planning step directly determines the actual generators, migrations, and routes you’ll write — skipping it is exactly how Rails apps end up with awkwardly nested resources, missing validations discovered only after bad data gets saved, or unnecessary actions nobody actually uses.
Decision Task
You’re planning a simple bookmarking feature: users can bookmark articles, and remove bookmarks, but never edit an existing bookmark’s details. Before reading on: which of the seven standard RESTful actions does the Bookmark resource genuinely need?
Show Answer
Likely just create (to bookmark) and destroy (to remove a bookmark), plus possibly index (to list a user’s bookmarks). new, edit, and update genuinely aren’t needed at all, since bookmarks are never edited after creation in this specific feature — generating all seven standard actions here would create unnecessary, unused code that doesn’t match the actual feature’s real requirements.
Common Mistake
Generating a full resources :bookmarks route (all seven standard actions) out of habit, without first considering which actions the specific feature genuinely needs. This creates unnecessary unused code and routes, when a more deliberately scoped route declaration (only the specific actions genuinely needed) would more accurately reflect the feature’s actual real requirements.
Practice Questions
1. Plan (in plain language, no code) the models and key associations for a simple event RSVP feature: users can RSVP yes/no to events.
Show Answer
Reasonable plan: an Event model (title, date), an RSVP model belonging to both Event and User (a join-model representing the many-to-many relationship), with a status attribute (yes/no) on RSVP.
2. In the blog example, why might comments only need index/create/destroy, not the full seven actions?
Show Answer
If comments genuinely aren’t meant to be editable after posting, edit and update serve no real purpose; new and show may also be unnecessary if comments are always created inline on the post’s own page rather than via a separate dedicated page.
3. Why does deciding on nesting (Part 4.3) belong in this planning step, rather than being decided arbitrarily while writing routes?
Show Answer
Nesting represents a genuine structural relationship decision — deciding it deliberately during planning, based on whether a resource genuinely can’t exist meaningfully without its parent, produces a more correct and maintainable route structure than an arbitrary choice made while writing code.
4. True or False: every resource in a Rails application should always use the full resources shortcut generating all seven standard actions.
Show Answer
False — this planning lesson’s point is that a resource should only get the specific actions its actual feature genuinely needs, which sometimes means a subset rather than the full seven.
5. What four planning questions does this lesson suggest asking before generating any Rails code?
Show Answer
What are the models and associations? Should any relationships be nested? Which of the seven standard actions does each resource genuinely need? What data needs validation?
Try It Yourself
Before moving to the next lesson, plan out (in plain language) the models, associations, and needed RESTful actions for a simple task-management feature of your own choosing. This isn’t graded, but skipping it will make the next lesson’s build harder to follow concretely.
This is an open, ungraded reflection exercise — there is no single correct answer to reveal.
Quick Check
1. What should happen before generating any Rails code for a new feature, according to this lesson?
Show Answer
A plain-language planning pass identifying models, associations, needed actions, and validations.
2. Should every resource always generate all seven standard RESTful actions?
Show Answer
No — only the specific actions a feature genuinely needs, which is sometimes a smaller subset.
3. Why does deciding on nesting belong in the planning stage?
Show Answer
It represents a genuine structural relationship decision best made deliberately, based on whether a resource can meaningfully exist without its parent.
4. In the bookmark example, which actions were identified as genuinely needed?
Show Answer
create, destroy, and possibly index — not the full seven.
5. Does planning only matter for complex Rails features?
Show Answer
No — even simple features benefit, since planning is what prevents unnecessary or awkwardly structured code regardless of complexity.