All right, welcome back, folks. Let's go ahead and dive in right where we left off at the end of the last video. So we now have a list of routes that can respond to a particular request type. So this means if I head back to my controllers, we can now clean these up, like you see right here, where we have a single controller that responds to a POST request for deleting the note, otherwise a GET request for showing the note. Yeah, now we can split these up into their own controller actions, so to speak. And if you remember, this was the entire point of the routing refactor to allow for this. Okay, so let's do this. In my routes file, let's see, this is the route for showing a note.

Okay, so let's do this. In my routes file, let's see, this is the route for showing a Note. So I'm going to duplicate it and say, this time listen for a DELETE request to that URI, and I will instead hit a controller like destroy.php. And again, that's a very common term. You're starting to see common terms like show and destroy and store and things like that. We'll keep touching on it. All right, so if I go back to the NotesController, actually, let's just do this. Let's copy the show controller and rename it to destroy.

All right, so if I go back to the NotesController, actually, let's just do this. Let's copy the show controller and rename it to destroy. But now I can clean this up quite a bit. I no longer have to do a conditional because we know we are responding to a DELETE request. So I can get rid of that and all of that, and we'll give it a reformat. Okay, so notice how with this refactor, I was able to remove quite a bit of indentation, and that's a very good thing, as you will come to find. Okay, so when we want to destroy a note, we still have this kind of sloppy code for initializing our database. We will fix that at some point in the near future.

our database. We will fix that at some point in the near future. We're still hard coding the current user ID because we haven't yet reviewed authentication. But again, we tackle that in the next chapter. And then we perform our authorization, and if that passes, we delete the note. But actually, real quick, I just noticed I accidentally used _GET. We actually want to check the $_POST super global. Sorry about that. And then otherwise, we redirect the user, and we're all set to go. Okay, so now I can close that.

And then otherwise, we redirect the user, and we're all set to go. Okay, so now I can close that. And if I switch back to the show action, once again, I no longer need any of this. I can remove all of the indentation and reformat. Yeah, looks good to me. Let's do a sanity check. In the browser, we go to our notes. Let's view a specific note and try to delete it. And there we go. Everything seems to be working.

And there we go. Everything seems to be working. But yeah, again, we've extracted that destroy action into its own file. And we were able to do that because we updated our router to listen and respond to different form request types. All right, makes sense. So now, well, actually, here's a cool thing. If I try to create a new note, I bet this fails because, again, we've tweaked our router. Do we get? Yes, we get a sorry page not found.

Do we get? Yes, we get a sorry page not found. And this makes sense if you think about it. We are now submitting a POST request to /note/create. But if I go into our routes here, well, we're not listening for a POST request. We're still using that old GET request. Okay, so we have one request to show the form to create a note. But then I will create a new route that instead listens for a POST request to this URI. And yeah, if you want, you can keep this URI we have. Remember, there's no real rules.

And yeah, if you want, you can keep this URI we have. Remember, there's no real rules. You can do whatever you want. But try to follow conventions whenever you can. And as it turns out, common RESTful conventions would say, if you want to add a new note, then you should make a POST request to the notes resource. That's the way we do it. Okay, and then for the action name, well, we would call it store again by common convention. It doesn't have to be store, but usually it is. And it's very helpful if you adopt these conventions because later,

It doesn't have to be store, but usually it is. And it's very helpful if you adopt these conventions because later, if somebody joins your team or you join a different team, if you're all kind of working with the same playbook, it becomes that much easier to instantly grok or grasp the code base. Okay, cool. So now if we come back, let's add a new controller here. And I'm just going to say hello to make sure that we are hitting this action. All right, let's go down to our views into create. And yeah, now our form will submit a POST request to notes.

All right, let's go down to our views into create. And yeah, now our form will submit a POST request to notes. All right, let's give it a shot. Come back to Firefox. Come back, refresh, try to submit the form. And there we go. Now we're hitting that new controller. Awesome. Okay, so once again, we can clean things up. I can go back to notes/create and grab this right here,

Okay, so once again, we can clean things up. I can go back to notes/create and grab this right here, remove it and place it within our new store action. There we go. I no longer need this conditional. So we are reducing indentation, which is good. And this is what we end up with. So it looks like I still need my DB class. Let's go ahead and grab that right up here. And yeah, I think this looks pretty good.

Let's go ahead and grab that right up here. And yeah, I think this looks pretty good. So we validate the request. And actually, real quick, let's add our errors initialization. And if we have no errors, we can insert the note into the database. And then finally, we can redirect the user wherever they need to go. How about /notes? And then we're done here. So we can die. Otherwise, if we reach this point, we have some kind of validation issue, don't we?

So we can die. Otherwise, if we reach this point, we have some kind of validation issue, don't we? So yeah, we could take this flow. But often I like to check for the problems first. And then the happy path can go at the bottom. So with that in mind, we could say, well, if errors is not empty, then the validation issue is here. Otherwise, we can continue on with the happy path right here. OK, so what should we do in the case that we have a validation issue? Well, we could redirect somewhere.

OK, so what should we do in the case that we have a validation issue? Well, we could redirect somewhere. Or we can just return the view, just like we did before. And then I will return that. All right, so this action or controller handles persisting a new Note to the database. And that's all. If I return to the create action for a Note, this one is now responsible for displaying a form to create the Note. So it ends up being a lot simpler. And in fact, we don't even use the database here.

So it ends up being a lot simpler. And in fact, we don't even use the database here. So I can inline our errors variable. And that's all we have here. It's actually pretty simple. All right, so let's give it a shot. Back to the browser. We will create a brand new Note. We persist it. That hits our new controller.

We persist it. That hits our new controller. We now see it here. We can view it. We can delete it, which also hits our destroy action. Everything's working. And again, this was made possible because we extended our router to respond to different request types. OK, so hopefully you're feeling comfortable. I'm going to pull the rug out from you one more time.