I will go into my Views, the one for displaying all notes, and then, yeah, maybe right here, hmm. Well, first, let's wrap this whole thing within an unordered list. And then, yeah, maybe right here we'll have a paragraph that includes a link to somewhere where that link's text is create note. And I'll need to style this as well. So I will make it blue, and then when you hover over it, we will underline it. Okay, so come back, give it a refresh, and yeah, maybe we should give it a little breathing room. March on top of six.

all of the logic here. And I don't know, maybe that's okay, but it might be cleaner if we extract these routes into their own file so that we don't have to see all this junk every single time we need to add or tweak a route. So with that in mind, let's create a new file, and it's just going to be called Routes. Then I will take these out, I'll cut it with Command X, and then move it over into our new file. Just like that. But next, instead of declaring a variable here, why don't we take the same approach as we did when we created the configuration file, where we just return directly from the

But next, instead of declaring a variable here, why don't we take the same approach as we did when we created the configuration file, where we just return directly from the file. Okay? So we'll swap this out with return. And then finally, if I go back to my router, I can now say right at the top, $routes equals require routes. Okay, and then finally, this URI variable, we can really put that down here if we want. Okay, and here's what we get. So if I come back to Firefox and give this a refresh, yeah, everything works exactly.

Okay, and here's what we get. So if I come back to Firefox and give this a refresh, yeah, everything works exactly the way it did before, but now we have this nice, clean, simple file we can visit whenever we need to add a new route. Okay, and as it turns out, we need to do that right now. So let's say, how about if you visit, I don't know, how about notes/create? That will take us to controllers/, and we could call it createNote, or why don't we reverse it? We'll say noteCreate. Okay, so why did I reverse it there?

We'll say note create. Okay, so why did I reverse it there? Well, it doesn't necessarily matter. It's just kind of a style thing. But notice, if we did call it create note.php, it is now separate from all of the other controllers related to notes. And remember, in real life, you could potentially have dozens and dozens of files. So again, it's not like it really matters, but it's often useful if we group them. And we can group them by beginning each controller with the word note or the corresponding resource. And again, on that note, keep in mind that you'll eventually learn how to create a single

And we can group them by beginning each controller with the word note or the corresponding resource. And again, on that note, keep in mind that you'll eventually learn how to create a single controller that can respond to multiple request types. But for now, we're just assuming one request, one route, one controller, and we'll keep it simple. Okay, so now, we'll say right here, as usual, we will require a view. And what should we call the view? Well, how about exact same thing, note_create.view.php. And I will duplicate this, note_create.view.php. And yeah, let's see what we can do here.

And I will duplicate this, note create.view.php. And yeah, let's see what we can do here. Get rid of that. And we'll just say create a note to make sure that it's working. Okay, so let's go back to our overview. And now, we have a place to link, notes/create. All right, let's give it a shot, back to Firefox. Give it a refresh. I click on create notes. And ooh, yeah, we forgot to declare a heading.

I click on create notes. And ooh, yeah, we forgot to declare a heading. But nonetheless, it does look like it's working. Okay, so let's fix that little issue. And we'll be off to the races. heading equals createNote. All right, and I think we're in business. So now, before I start working on the form, why don't we have a quick little conversation about naming conventions for your routes? So of course, remember, there's no rules.

about naming conventions for your routes? So of course, remember, there's no rules. You can name these whatever you want. But that being said, there are guidelines where it's useful to follow them, to be honest. If you're working with other people, it can be useful if you all follow the same guidelines. That way, your approach is going to be pretty similar to Joe's or Sarah's approach if you work on the same team. Okay, so I want you to notice these three routes here. /notes would be a page to view all of the notes. And we can see that right here.

Slash notes would be a page to view all of the notes. And we can see that right here. Show me a list of the notes. Slash notes would be a page to view a single note. Or in fact, eventually, once you learn about routes, parameters, or wildcards, you might see something like this. notes slash, and then you'd have some kind of wildcard like we learned with prepared statements where you could do something like that. And that would say, okay, listen for notes slash, and then some kind of identifier or a slug.

And that would say, okay, listen for notes slash, and then some kind of identifier or a slug. notes/1 would show me the note with an ID of one. notes/4 would show me the note with an ID of four. But yeah, for now, we're just keeping it simple because we don't have a complex router and we've named it /note. And then finally, we have one called /notes/create, which of course would display a form to create a note. So again, notice that I'm not calling these like viewNote, createNote. And yeah, there's nothing preventing me from doing this.

So again, notice that I'm not calling these like view note, create note. And yeah, there's nothing preventing me from doing this. I could do it if I want, but I don't love it. And further, I'm a big fan of following conventions for the community you work in, following common conventions. And I think you'll find in our space, people often follow what's known as a RESTful approach. And I don't want to get into REST. It's not appropriate. And it's too soon to talk about that. But for now, I just want you to notice the pattern.

And it's too soon to talk about that. But for now, I just want you to notice the pattern. So imagine any resource you have. It could be notes. It could be posts. It could be users. It could be anything. If you're building a photo app, then your resource would be photos. Well, you might have a URI called /photos to view all photos. You might have a URI like /photo or /photos/, and then the ID for viewing.

Well, you might have a URI called /photos to view all photos. You might have a URI like /photo or /photos/{id}, and then the ID for viewing a specific photo. You might have a URI like /photos/create to display a page or a form to create a photo. So again, I want you to notice this system and this pattern that I'm following. And later, you'll learn how to respond to specific request types like a POST request or a PUT request or a DELETE request. OK, a little tangent there, but file that one away for later. All right, let's get back to work.

OK, a little tangent there, but file that one away for later. All right, let's get back to work. So into our view, we're now going to display a form. So I will add a form here. And we're going to start with the most bare bones form. And then at the end of the video, we'll pull in a fancy looking form from Tailwind. OK, so we might start, well, actually, before we do that, let's go to TablePlus into Notes. And yeah, we can see the form we need to create will correspond to the table here. So really, this is a simple one right now. All I need is a body.

So really, this is a simple one right now. All I need is a body. So yeah, if we took the simplest possible approach, I would have a textarea. I'd have a name that corresponds to, and it doesn't have to, but frequently, it will correspond to the column in the corresponding table. And then you would have some kind of button. So again, this is not going to look pretty, but we're making it super quick to test things out. All right, so go back to Firefox. Give it a refresh. I'm sorry, create notes.

Give it a refresh. I'm sorry, create notes. And yeah, that's all we get, a very unstyled form. OK, so now let's just see what would happen, some new note idea. I submit the form, and it looks like it disappears, but we can actually see that the page did refresh, and now the form data is included as part of the query string. OK, very interesting, and in fact, one little thing I should show you. If I did not include a name on the text area, let's try it again. All right, one more time, create, and notice this time it is not included. So you probably already know this, but just to make sure we're all on the same page, you

All right, one more time, create, and notice this time it is not included. So you probably already know this, but just to make sure we're all on the same page, you want to make sure that all of your form inputs, or I'm sorry, form inputs include a corresponding name. All right, so now why don't we make my editor happy. It's squawking because I haven't included a label, so we'll do that now. Label for, and this wants the name of a corresponding input's ID, not the name, but ID. So often you'll see people double up here. They'll give an ID and a name, and usually it's for this purpose. OK, so let's say label for body, and then we'll say, you know, it doesn't have to be

OK, but anyways, yeah, I can fill out this form, and when I submit it, it seems like it just refreshes the page and updates the query string, and this is a GET request. So by default, a form will submit using a GET request. And as it turns out, things like this, GET request, GET request, GET request, GET request, get me that page, but it's not the only request type you can make. There's many more, and one of those other types is a POST request. So why don't we tweak this and say form method is POST. All right, and I won't change anything else here. Let's just see what happens. So I submit the form, and it refreshes again.

And then finally, last little thing I'll note on this, technical term incoming, sorry about that. With a GET request, they should be considered idempotent, and that just means no matter how many times you make the request, whether I do this one time or 10,000 times, I'm not doing anything destructive. I'm still going to get the same results. But that is not true for things like submitting a form. So if I submitted this form, and once it's complete, we would persist a new Note in the database. So that means if I did this 10,000 times, wouldn't I have 10,000 records in the database?

database. So that means if I did this 10,000 times, wouldn't I have 10,000 records in the database? That is not idempotent, so we should not use a GET request for this form submission. Okay, but now, yeah, that begs the question, well, I fill it out, I submit it, where did it go? All right, let's have a look. Let's go back to note create, and why don't we do this? I'm going to die and dump the server, like we did many episodes ago. All right, let's do it again, submit it, and here's what we get. So yeah, let's just inspect this and see if there's anything relevant.

All right, let's do it again, submit it, and here's what we get. So yeah, let's just inspect this and see if there's anything relevant. Lots of information about my computer, but then I do see this one here, request method, POST. Hmm. Let's try reloading the page. All right, now we do it. request method is GET, and of course, I visited the page, and that's a GET request. But when I submitted the form, I changed the request type to POST. So that's why it's GET when I visit the form, like that.

But when I submitted the form, I changed the request type to POST. So that's why it's GET when I visit the form, like that. But then when I submit the form and it reloads this page, it changes to POST. Okay, so I think we can inspect that. Let's do this. When the page loads, why don't we say, well, if the server, and I'm just grabbing this right here, if the request method equals POST, well, then we know at this point we are responding to the submission of the form. You submitted the form. All right, let's give it a try.

You submitted the form. All right, let's give it a try. Fill it out. Submit. You submitted the form. So now we have a way to distinguish between a GET request to this URI and a POST request to this URI. Cool. But yeah, now the next thing, how do I get information from the form? And as it turns out, we have a new superglobal, $_POST.

But yeah, now the next thing, how do I get information from the form? And as it turns out, we have a new superglobal, $_POST. All right, let's see what happens. Refresh. And there we go. Notice I have an array of all of the attributes from the form. All right, cool. So now, if you think about it, we've added a form, and we figured out how we can respond to the submission of the form. We've learned how we can grab all of the data or the attributes from the form.

So let's come back to Firefox and take a look. And yeah, I think we're most of the way there. One little issue, notice how the form input is not displaying quite like their version. Let's see why. We'll go to the top here, and they have a little note. So it looks like this example requires a forms plugin. But luckily, this should be pretty easy to add because we are referencing Tailwind through its CDN. So I will visit my head section. And yeah, I think it says easy as saying plugins equal form.

Yeah, this is kind of what's cool about Tailwind is you can grab it and then just use whatever is necessary and throw away the rest. So let's see how that looks. Mm-hmm. I don't think we need a little descriptor. So I can get rid of that. Good. Okay. So let's change this to body. It's a textarea.

So let's change this to body. It's a text area. And once again, I'm just going to bring it right back to what we had before, where we have an ID and name of body, because that is the name of the column. So finally, we have a form here. It is making a POST request. And then, yeah, this action attribute may or may not be new to you. That just specifies where the request should go. So by default, if it's not included, that means we are submitting to the current page. But it doesn't have to be that way.

So by default, if it's not included, that means we are submitting to the current page. But it doesn't have to be that way. If you want to do something like this, make newNote, well, now it's going to make a POST request to this URI instead of the current page. And yeah, we sort of talked about a RESTful system. Eventually, you might do something like this. And that would say, all right, we're going to make a POST request to /notes to create and persist a new note in the database. But for now, I'm just going to keep it to submitting to the current page. All right.