Currently, our Add Entry form redisplays itself

after successfully adding a new entry.

Ideally, it should display the entry's list page.

Let's update our controller's Add Action method to do exactly that.

Right after the call to the repository's Add Entry method,

let's return a call to the view method.

Returning here will prevent the return statement at the bottom of the method

from being executed, which is the behavior that we're looking for.

If we call the view method without any parameters, MVC will return the view

whose name matches our action method name, which, in this case, is add.

We can override that default behavior by supplying the name of the view we want to

render.

So I'll pass in this string index, which is the view for our entries list page.

Let's remove our breakpoint, and press F5 to run our app.

I'll change the activity field value to 1 and duration to 23 and save the form.

And we got an error, cannot perform runtime binding on a null reference.

That's right, our list page view requires us to supply

a couple of ViewBag property values, not to mention a collection of entries.

Go ahead and stop the app.

This is not the way to do this, but let's work around this issue for

now by copying and pasting the contents of the index method down into our add method.

We also need to update our view method call by

passing the entries collection after our view name.

Okay, let's run our app again.

Set our form values.

And save the form.

All right, no error this time, that's progress.

And here's our new entry at the top of the list, but this is interesting.

Take a look at the URL.

It's the path to our Add Entry page,

localhost:52784/Entries/Add, that's not good.

I wonder what will happen if I refresh the page.

No, Chrome is displaying the infamous confirm form resubmission dialog,

which is letting us know that if we continue with refreshing the page,

that our previous action might be repeated.

Let's click the Continue button to see what happens.

And there it is, our new entry has been added again.

Let's go ahead and stop the app.

Why is this happening?

Well, the last request that we made was the post

that we initiated when we clicked the Save button.

And while we return the content for

the entries list page, we didn't send the user to a new page.

Because of that, the latest entry in the browser's history

is the post request from the Add Entry page, so

refreshing the page causes the post request to be sent to the server again.

How do we prevent users from accidentally re-submitting the form data?

It's simple, really.

We just need to redirect the user to a new page after saving the new entry.

MVC makes this easy by providing the redirect to action method.

We just need to supply the name of the action to redirect to.

[SOUND] By returning this method call,

MVC will return a response with a 302 FOUND HTTP status code,

along with the location header that contains the URL to redirect the user to.

When the browser receives our response, it detects a 302 status code and

makes a GET request to the URL from the location header.

The end result is that the user will see the entries list page.

And the latest entry in the browser's history is now the GET request for

that page, instead of the post request from the Add Entry page.

This solution is called the post/redirect/get pattern.

It's a commonly used web development design pattern for

preventing duplicate form submissions.

See the teacher's notes for more information.

Let's test our fix.

I'll enter my values and save the form again.

Here's our new entry at the top of the list.

Now I'll refresh the page.

Great, we've prevented the duplicate form submission.

Go ahead and stop the app, and if you're using GitHub, let's commit our changes.

Enter a commit message of Updated the "Add Entry"

page to redirect to the "Entry" list page,

and click the Commit All button.

We've done a number of local commits.

So, now would be a good time to sync with the remote server.

Click sync here in this confirmation message

to navigate to the synchronization panel.

Here's a list of our local commits in the outgoing commit section.

Click the Push link to push these commits to the server.

Let's do a quick review.

We learned how to add an action method to our controller to process POST requests.

We saw how MVC's model binding can be used to extract form field values

from the request and how ModelState gives us access

to the underlying form field values and related errors.

We also learned how to leverage MVC's HTML helper methods

to create form field elements.

And we saw how to use the Post/Redirect/Get design pattern

to prevent duplicate form submissions.

We've covered a lot of ground so far.

Keep up the great work.

There's still a lot left to do before we're done with our Fitness Frog Web App.

In the next section, we'll see how we can use dropdown lists, radio buttons,

and check boxes to make it easier for our users to use our form.