1 00:00:00,530 --> 00:00:04,080 Currently, our Add Entry form redisplays itself 2 00:00:04,080 --> 00:00:06,840 after successfully adding a new entry. 3 00:00:06,840 --> 00:00:10,200 Ideally, it should display the entry's list page. 4 00:00:10,200 --> 00:00:14,650 Let's update our controller's Add Action method to do exactly that. 5 00:00:14,650 --> 00:00:18,460 Right after the call to the repository's Add Entry method, 6 00:00:18,460 --> 00:00:20,830 let's return a call to the view method. 7 00:00:20,830 --> 00:00:25,250 Returning here will prevent the return statement at the bottom of the method 8 00:00:25,250 --> 00:00:29,500 from being executed, which is the behavior that we're looking for. 9 00:00:29,500 --> 00:00:34,530 If we call the view method without any parameters, MVC will return the view 10 00:00:34,530 --> 00:00:38,910 whose name matches our action method name, which, in this case, is add. 11 00:00:38,910 --> 00:00:43,484 We can override that default behavior by supplying the name of the view we want to 12 00:00:43,484 --> 00:00:44,041 render. 13 00:00:44,041 --> 00:00:50,230 So I'll pass in this string index, which is the view for our entries list page. 14 00:00:50,230 --> 00:00:55,023 Let's remove our breakpoint, and press F5 to run our app. 15 00:00:57,277 --> 00:01:04,020 I'll change the activity field value to 1 and duration to 23 and save the form. 16 00:01:06,120 --> 00:01:11,020 And we got an error, cannot perform runtime binding on a null reference. 17 00:01:12,210 --> 00:01:16,300 That's right, our list page view requires us to supply 18 00:01:16,300 --> 00:01:20,850 a couple of ViewBag property values, not to mention a collection of entries. 19 00:01:20,850 --> 00:01:22,631 Go ahead and stop the app. 20 00:01:31,028 --> 00:01:35,436 This is not the way to do this, but let's work around this issue for 21 00:01:35,436 --> 00:01:41,056 now by copying and pasting the contents of the index method down into our add method. 22 00:01:59,084 --> 00:02:01,884 We also need to update our view method call by 23 00:02:01,884 --> 00:02:05,300 passing the entries collection after our view name. 24 00:02:11,827 --> 00:02:14,213 Okay, let's run our app again. 25 00:02:16,519 --> 00:02:18,324 Set our form values. 26 00:02:20,405 --> 00:02:22,022 And save the form. 27 00:02:26,392 --> 00:02:30,270 All right, no error this time, that's progress. 28 00:02:30,270 --> 00:02:35,130 And here's our new entry at the top of the list, but this is interesting. 29 00:02:35,130 --> 00:02:38,840 Take a look at the URL. 30 00:02:38,840 --> 00:02:42,821 It's the path to our Add Entry page, 31 00:02:42,821 --> 00:02:49,638 localhost:52784/Entries/Add, that's not good. 32 00:02:49,638 --> 00:02:52,804 I wonder what will happen if I refresh the page. 33 00:02:54,901 --> 00:02:59,768 No, Chrome is displaying the infamous confirm form resubmission dialog, 34 00:02:59,768 --> 00:03:04,254 which is letting us know that if we continue with refreshing the page, 35 00:03:04,254 --> 00:03:07,950 that our previous action might be repeated. 36 00:03:07,950 --> 00:03:11,100 Let's click the Continue button to see what happens. 37 00:03:11,100 --> 00:03:15,160 And there it is, our new entry has been added again. 38 00:03:16,600 --> 00:03:18,230 Let's go ahead and stop the app. 39 00:03:19,590 --> 00:03:21,310 Why is this happening? 40 00:03:21,310 --> 00:03:24,980 Well, the last request that we made was the post 41 00:03:24,980 --> 00:03:27,910 that we initiated when we clicked the Save button. 42 00:03:27,910 --> 00:03:29,740 And while we return the content for 43 00:03:29,740 --> 00:03:34,570 the entries list page, we didn't send the user to a new page. 44 00:03:34,570 --> 00:03:38,590 Because of that, the latest entry in the browser's history 45 00:03:38,590 --> 00:03:42,790 is the post request from the Add Entry page, so 46 00:03:42,790 --> 00:03:47,940 refreshing the page causes the post request to be sent to the server again. 47 00:03:47,940 --> 00:03:51,990 How do we prevent users from accidentally re-submitting the form data? 48 00:03:51,990 --> 00:03:53,230 It's simple, really. 49 00:03:53,230 --> 00:03:58,480 We just need to redirect the user to a new page after saving the new entry. 50 00:03:58,480 --> 00:04:03,250 MVC makes this easy by providing the redirect to action method. 51 00:04:03,250 --> 00:04:06,806 We just need to supply the name of the action to redirect to. 52 00:04:10,732 --> 00:04:13,741 [SOUND] By returning this method call, 53 00:04:13,741 --> 00:04:18,818 MVC will return a response with a 302 FOUND HTTP status code, 54 00:04:18,818 --> 00:04:24,949 along with the location header that contains the URL to redirect the user to. 55 00:04:24,949 --> 00:04:30,527 When the browser receives our response, it detects a 302 status code and 56 00:04:30,527 --> 00:04:34,636 makes a GET request to the URL from the location header. 57 00:04:34,636 --> 00:04:39,460 The end result is that the user will see the entries list page. 58 00:04:39,460 --> 00:04:44,410 And the latest entry in the browser's history is now the GET request for 59 00:04:44,410 --> 00:04:48,340 that page, instead of the post request from the Add Entry page. 60 00:04:49,540 --> 00:04:54,783 This solution is called the post/redirect/get pattern. 61 00:04:54,783 --> 00:04:58,530 It's a commonly used web development design pattern for 62 00:04:58,530 --> 00:05:01,130 preventing duplicate form submissions. 63 00:05:01,130 --> 00:05:03,200 See the teacher's notes for more information. 64 00:05:04,720 --> 00:05:06,089 Let's test our fix. 65 00:05:10,813 --> 00:05:15,855 I'll enter my values and save the form again. 66 00:05:17,446 --> 00:05:20,730 Here's our new entry at the top of the list. 67 00:05:20,730 --> 00:05:22,982 Now I'll refresh the page. 68 00:05:25,745 --> 00:05:29,550 Great, we've prevented the duplicate form submission. 69 00:05:29,550 --> 00:05:34,320 Go ahead and stop the app, and if you're using GitHub, let's commit our changes. 70 00:05:39,283 --> 00:05:45,962 Enter a commit message of Updated the "Add Entry" 71 00:05:45,962 --> 00:05:51,861 page to redirect to the "Entry" list page, 72 00:05:51,861 --> 00:05:56,230 and click the Commit All button. 73 00:05:58,420 --> 00:06:00,700 We've done a number of local commits. 74 00:06:00,700 --> 00:06:04,410 So, now would be a good time to sync with the remote server. 75 00:06:04,410 --> 00:06:07,580 Click sync here in this confirmation message 76 00:06:07,580 --> 00:06:09,940 to navigate to the synchronization panel. 77 00:06:09,940 --> 00:06:14,170 Here's a list of our local commits in the outgoing commit section. 78 00:06:14,170 --> 00:06:17,381 Click the Push link to push these commits to the server. 79 00:06:20,213 --> 00:06:22,420 Let's do a quick review. 80 00:06:22,420 --> 00:06:27,430 We learned how to add an action method to our controller to process POST requests. 81 00:06:27,430 --> 00:06:32,680 We saw how MVC's model binding can be used to extract form field values 82 00:06:32,680 --> 00:06:36,420 from the request and how ModelState gives us access 83 00:06:36,420 --> 00:06:40,140 to the underlying form field values and related errors. 84 00:06:40,140 --> 00:06:44,790 We also learned how to leverage MVC's HTML helper methods 85 00:06:44,790 --> 00:06:46,990 to create form field elements. 86 00:06:46,990 --> 00:06:51,890 And we saw how to use the Post/Redirect/Get design pattern 87 00:06:51,890 --> 00:06:54,460 to prevent duplicate form submissions. 88 00:06:54,460 --> 00:06:56,750 We've covered a lot of ground so far. 89 00:06:56,750 --> 00:06:58,390 Keep up the great work. 90 00:06:58,390 --> 00:07:02,660 There's still a lot left to do before we're done with our Fitness Frog Web App. 91 00:07:02,660 --> 00:07:07,970 In the next section, we'll see how we can use dropdown lists, radio buttons, 92 00:07:07,970 --> 00:07:11,665 and check boxes to make it easier for our users to use our form.