Modifying Nested Resources
Objectives
Understand how to handle modifications (create/update) of nested resources.
Handle errors and validate data from nested resources.
Review the use of view helpers to keep views clean.
Lesson
Continuing with our blog application, we're going to extend our nested resources to allow for creating and modifying blog posts by author.
Creating A New Post For An Author
The first thing we want to do is to create a new post that is automatically linked to an Author
. We could set up a select box on the post page and make the user choose an author. However, if we're already on the author's new post page, we know who the author is, so why not do it without forcing the user to choose?
We already used nested resources to view posts by author, so now let's look at nested resources to create posts by author. As usual, we want to start with the route. We want to add :new
to our nested :posts
resource:
This gives us access to /authors/:author_id/posts/new
, and a new_author_post_path
helper.
Top-tip: Remember to run rake routes
if you're unsure of the URL helper name.
We have the route, so now we need to update our posts_controller#new
action to handle the :author_id
parameter.
Notice that we're passing the params[:author_id]
into Post.new()
. We want to make sure that, if we capture an author_id
through a nested route, we keep track of it and assign the post to that author. We'll actually be carrying this id
with us for the next few steps, babysitting it through the server request/response cycle.
Now let's get into our author show
template and add a link to the nested new post page for that author.
Let's launch the app (don't forget to rake db:seed
), browse to /authors
, click on an author's name, and then click the new post link. Once there, let's make a post.
Something seems off. Where's our author? Looks like we didn't do a great job babysitting that author_id
. We set it up in the new
action, but it never made it to the view so that it could get submitted back to the server. Let's fix that. Open up the post form partial and add a hidden field for the :author_id
.
If we reload the new post page for the author and inspect the source, we should see something like this:
Great. That part's working, but we need to carry that author_id
with us even further.
Now we know the author_id
will be allowed for mass-assignment in the create
action.
Let's try it out. Go to an author's new post page, and make a post. We should see the author's name in the byline now!
Why didn't we have to make a nested resource route for :create
in addition to :new
?
The form_for(@post)
helper in posts/_form.html.erb
will automatically route to POST posts_controller#create
for a new Post
. By carrying the author_id
as we did and allowing it through strong parameters, the existing create
route and action can be used without needing to do anything else.
Editing An Author's Posts
We can use the same technique to allow us to directly edit an author's posts.
First, we allow the :edit
action in the nested route:
We don't have to change any views because new
and edit
both use the same _form
partial that already has the author_id
.
Now we need to update our post show
view to give us the new nested link to edit the post for the author.
We need to make one small change to the controller:
Now if we try it out, everything should work just fine. Reload the page, click the edit link, and edit the post.
Pretty easy, right? What's the catch?
Handling Mischief And Errors In Our URLs
The catch is that we've opened ourselves up to a couple of potential bugs or, worse, opportunities for our more playful users to make a mess of our data. Let's work backward, starting with our recent changes to edit
.
If you go back to your author post edit page, you'll see a URL similar to http://localhost:3000/authors/1/posts/1/edit
. This tells us that we are editing the Post
with id: 1
by the Author
with id: 1
. But what if we change that author_id
in the URL? Try browsing to http://localhost:3000/authors/123456/posts/1/edit
, and see what happens.
We end up on the same page! But post 1
belongs to author 1
— not author 123456
. In fact, there is no author 123456
in the system. How is this happening?
Remember how we didn't have to change the controller when we added the nested resource route for :edit
? Well, this is the price we pay for taking shortcuts. What we should do is check to make sure that 1) the author_id
is valid and 2) the post matches the author. So let's fix that now.
Here we're looking for the existence of params[:author_id]
, which we know would come from our nested route. If it's there, we want to make sure that we find a valid author. If we can't, we redirect them to the authors_path
with a flash[:alert]
.
If we do find the author, we next want to find the post by params[:id]
, but, instead of directly looking for Post.find()
, we need to filter the query through our author.posts
collection to make sure we find it in that author's posts. It may be a valid post id
, but it might not belong to that author, which makes this an invalid request.
Now if we go back and try our invalid URL (http://localhost:3000/authors/123456/posts/1/edit
), we should be redirected back to where we belong.
While we're at it, we should fix up our new
action to ensure that we're creating a new post for a valid author. Let's make it look like this:
Here we check for params[:author_id]
and then for Author.exists?
to see if the author is real.
Why aren't we doing a find_by
and getting the author instance? Because we don't need a whole author instance for Post.new
; we just need the author_id
. And we don't need to check against the posts
of the author because we're just creating a new one. So we use exists?
to quickly check the database in the most efficient way.
But what if params[:author_id]
is nil
in the example above? If we just did Post.new
without the (author_id: params[:author_id])
argument, the author_id
attribute of the new Post
would be initialized as nil
anyway. So we don't have to do anything special to handle it. It works for us if there is or isn't an author_id
present.
Which brings us to the last thing we have to do.
Missing Authors
When someone creates a new post via our nested route, we automatically assign an author, and everything works great. But what about when they create a new post from the regular old new_post_path
?
We could just eliminate that route and only allow post creation through the nested resource. That might be a valid choice in some applications.
But we've decided we want to be able to select an author at the time of posting if we haven't used the nested route.
Since we're already set up to handle author_id
on the controller, all we have to do is augment our posts/_form.html.erb
partial to present a list of authors when none is present.
That gives us a select control if we don't have an author, but we have a problem. We can only have one :author_id
field. We could put that hidden_field
in an else
, which would work, but then we would have a whole bunch of logic cluttering up our view. So let's dump it in our posts_helper
and clean up that form.
And back in our form partial:
Now we should have a selector when we browse to /posts/new
and a hidden author_id
field when we browse to /authors/1/posts/new
.
Summary
We've seen how to create and edit nested resources, handle for errors or mischievous users in our parameters, and use helpers to extend our views to handle for nested and non-nested versions of the resource.
You're well on your way to becoming a nested resource ninja!
Last updated