Redirecting Back to the List Page7:12 with James Churchill
Let’s update our controller’s “Add” action method to display the “Entries” list page after successfully adding a new entry.
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
See this Wikipedia page for more information about the Post/Redirect/Get design pattern.
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 up