This course will be retired on June 1, 2025.
Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Let’s update our controller’s “Add” action method to display the “Entries” list page after successfully adding a new entry.
Follow Along
To follow along commiting your changes to this course, you'll need to fork the aspnet-fitness-frog repo. Then you can clone, commit, and push your changes to your fork like this:
git clone <your-fork>
cd aspnet-fitness-frog
git checkout tags/v2.9 -b redirecting-back-to-the-list-page
Additional Learning
See this Wikipedia page for more information about the Post/Redirect/Get design pattern.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
Currently, our Add Entry
form redisplays itself
0:00
after successfully adding a new entry.
0:04
Ideally, it should display
the entry's list page.
0:06
Let's update our controller's
Add Action method to do exactly that.
0:10
Right after the call to
the repository's Add Entry method,
0:14
let's return a call to the view method.
0:18
Returning here will prevent the return
statement at the bottom of the method
0:20
from being executed, which is
the behavior that we're looking for.
0:25
If we call the view method without any
parameters, MVC will return the view
0:29
whose name matches our action method name,
which, in this case, is add.
0:34
We can override that default behavior by
supplying the name of the view we want to
0:38
render.
0:43
So I'll pass in this string index, which
is the view for our entries list page.
0:44
Let's remove our breakpoint,
and press F5 to run our app.
0:50
I'll change the activity field value to
1 and duration to 23 and save the form.
0:57
And we got an error, cannot perform
runtime binding on a null reference.
1:06
That's right,
our list page view requires us to supply
1:12
a couple of ViewBag property values,
not to mention a collection of entries.
1:16
Go ahead and stop the app.
1:20
This is not the way to do this, but
let's work around this issue for
1:31
now by copying and pasting the contents of
the index method down into our add method.
1:35
We also need to update
our view method call by
1:59
passing the entries collection
after our view name.
2:01
Okay, let's run our app again.
2:11
Set our form values.
2:16
And save the form.
2:20
All right, no error this time,
that's progress.
2:26
And here's our new entry at the top
of the list, but this is interesting.
2:30
Take a look at the URL.
2:35
It's the path to our Add Entry page,
2:38
localhost:52784/Entries/Add, that's
not good.
2:42
I wonder what will happen
if I refresh the page.
2:49
No, Chrome is displaying the infamous
confirm form resubmission dialog,
2:54
which is letting us know that if we
continue with refreshing the page,
2:59
that our previous action
might be repeated.
3:04
Let's click the Continue
button to see what happens.
3:07
And there it is,
our new entry has been added again.
3:11
Let's go ahead and stop the app.
3:16
Why is this happening?
3:19
Well, the last request
that we made was the post
3:21
that we initiated when we
clicked the Save button.
3:24
And while we return the content for
3:27
the entries list page,
we didn't send the user to a new page.
3:29
Because of that,
the latest entry in the browser's history
3:34
is the post request from
the Add Entry page, so
3:38
refreshing the page causes the post
request to be sent to the server again.
3:42
How do we prevent users from accidentally
re-submitting the form data?
3:47
It's simple, really.
3:51
We just need to redirect the user to
a new page after saving the new entry.
3:53
MVC makes this easy by providing
the redirect to action method.
3:58
We just need to supply the name
of the action to redirect to.
4:03
[SOUND] By returning this method call,
4:10
MVC will return a response with
a 302 FOUND HTTP status code,
4:13
along with the location header that
contains the URL to redirect the user to.
4:18
When the browser receives our response,
it detects a 302 status code and
4:24
makes a GET request to the URL
from the location header.
4:30
The end result is that the user
will see the entries list page.
4:34
And the latest entry in the browser's
history is now the GET request for
4:39
that page, instead of the post
request from the Add Entry page.
4:44
This solution is called
the post/redirect/get pattern.
4:49
It's a commonly used web
development design pattern for
4:54
preventing duplicate form submissions.
4:58
See the teacher's notes for
more information.
5:01
Let's test our fix.
5:04
I'll enter my values and
save the form again.
5:10
Here's our new entry at
the top of the list.
5:17
Now I'll refresh the page.
5:20
Great, we've prevented
the duplicate form submission.
5:25
Go ahead and stop the app, and if you're
using GitHub, let's commit our changes.
5:29
Enter a commit message of
Updated the "Add Entry"
5:39
page to redirect to the "Entry" list page,
5:45
and click the Commit All button.
5:51
We've done a number of local commits.
5:58
So, now would be a good time to
sync with the remote server.
6:00
Click sync here in this
confirmation message
6:04
to navigate to the synchronization panel.
6:07
Here's a list of our local commits
in the outgoing commit section.
6:09
Click the Push link to push
these commits to the server.
6:14
Let's do a quick review.
6:20
We learned how to add an action method to
our controller to process POST requests.
6:22
We saw how MVC's model binding can
be used to extract form field values
6:27
from the request and
how ModelState gives us access
6:32
to the underlying form field values and
related errors.
6:36
We also learned how to leverage
MVC's HTML helper methods
6:40
to create form field elements.
6:44
And we saw how to use
the Post/Redirect/Get design pattern
6:46
to prevent duplicate form submissions.
6:51
We've covered a lot of ground so far.
6:54
Keep up the great work.
6:56
There's still a lot left to do before
we're done with our Fitness Frog Web App.
6:58
In the next section, we'll see how we
can use dropdown lists, radio buttons,
7:02
and check boxes to make it easier for
our users to use our form.
7:07
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up