So if you decide that you want to perform your request validation outside of the controller action itself, in these cases, I'd recommend creating a dedicated form request class. But before I show you how to do that, I wanna emphasize one point, bring it in. It doesn't make you better. So it's just a choice and one is as good as the other. It just depends on what you're building and what kind of flexibility you might need.

It just depends on what you're building and what kind of flexibility you might need. So I say that because if you wanna do your validation in line, that's great, no problem. If you wanna do your validation in a dedicated class, great, it's no problem. But one way or the other, it doesn't make you better, it doesn't make you smarter, it doesn't make you, um, more of, um, an advocate for design patterns or single respond. It doesn't matter. It's just a decision you make.

of, um, an advocate for design patterns or single respond. It doesn't matter. It's just a decision you make. And if you have a good reason for it, stick to it. Okay, let's get going. So I'm gonna delete this or let's just comment it out temporarily and we're gonna generate a new form request class. So again, whenever you feel like you need to make a new file type, well, don't forget Laravel Artisan command line, uh, helper

to make a new file type, well, don't forget Laravel Artisan command line, uh, helper or utility can do it for you. Peach B Artisan, make a new form request class. And what should it be named? Well, let's follow this convention, uh, store idea request. Alright, so now that's gonna go in a new request directory, and we will find that right up here. App HTTP requests. Okay, so this will consist of by default, two things.

App HTTP requests. Okay, so this will consist of by default, two things. First step, you can perform your authorization directly within this class. So think about it is the u forget about validation, is the user even authorized to make this request? So in, in our case, anyone can do it, but imagine a situation where no, if you are not signed in, then you're not authorized to add new entries to my database.

then you're not authorized to add new entries to my database. Or if you're not signed in and you're not the person who created this project, then you're not allowed to add ideas to that project. You are unauthorized. And if you want, you can perform those checks here. So yeah, you can maybe do things like grab the authenticated user once we work on that and then determine are you authorized to create a new idea?

user once we work on that and then determine are you authorized to create a new idea? And you can perform this kind of logic right here. But for now, we're not at authorization yet. So just put a pen in this and we will come back to it later. For now, we'll say, yeah, anyone's authorized, let's move on to the next step. The validation rules. And these rules are the exact same things we worked on in the last episode. So that means I can grab this right here and paste it in.

things we worked on in the last episode. So that means I can grab this right here and paste it in. That's it. So now we have a dedicated method that contains our validation rules. All right, so here's the cool thing. I I will say, here's the cool thing about form request classes. Look, this extends something called form request. And if I, uh, if I open it, that extends the same request instance

And if I, uh, if I open it, that extends the same request instance that we were originally typing within our controller as a parameter. So that means a store idea request is a request, which means I can substitute it, I can swap this out with store idea. Where are you? There it is. I can swap it out and still interact with it in the same way as I would interact with any request instance.

I can swap it out and still interact with it in the same way as I would interact with any request instance. So here's the cool thing. I no longer have to call validate at all. That's going to happen automatically. And again, this is some of flare of Hell's Magic. It knows if you're typing a form request class. Alright, before I even give it to you, let me see if it's in a valid state or not. Alright, so I'm not gonna do anything else here.

let me see if it's in a valid state or not. Alright, so I'm not gonna do anything else here. I'm gonna switch back to the browser and test it out. Let's not provide anything. All right, description field is required. Let's provide one letter and now we get the other validation rule. It's working and yeah, maybe you prefer this and I have to admit, it's, it's pretty cool stuff. You can even configure it and have a lot more flexibility.

and I have to admit, it's, it's pretty cool stuff. You can even configure it and have a lot more flexibility. For example, lemme show you a couple things if you want. You can override the messages method. So this is responsible for displaying the, uh, the failed validation message. So for example, yeah, here's a, a good auto complete. You can give it the name of the field and then dots and the name of the validation rule. In this case, we're saying, well, in the event

and the name of the validation rule. In this case, we're saying, well, in the event that description fails validation because of this rule, then I'm gonna set the message to description is required. So let's give it a shot, submit it, and whoops, what did I forget? Sorry, one more time and description is required. So we could, if you wanna have some fun, you could say, come on dude, gimme something.

So we could, if you wanna have some fun, you could say, come on dude, gimme something. Alright, come back. Lame. I know. Uh, but sure enough, you have a little flexibility here if you want to inject some personality into your validation, which is cool. Um, what else? If you want a little more clarity, um, you could say, give me something four and we're gonna use this magic syntax here. Colon attributes.

and we're gonna use this magic syntax here. Colon attributes. This of course is going to reference the name of the attribute that you are validating. So once again, give me something for description and if this were attached to an email input and maybe you could write, give me something for email, you get the idea. Uh, but of course this is optional and you don't have to do it.

Uh, but of course this is optional and you don't have to do it. Cool. Alright, so let's make this happy. And yeah, now you've learned that form request classes can be generated from the command line. They allow you to perform authorization if relevant. Oh, and by the way, if it's set to return false, this means you can forget about validation authorization fails, which means you can't do anything.

this means you can forget about validation authorization fails, which means you can't do anything. So if I were to come back and submit this, we're gonna get a 4 0 3, you are not authorized because we returned false. So keep that in mind. All right, next, you can declare your validation rules in exactly the way that we declared them in the last episode. So again, once again, if you had some email input that we're gonna validate email

So again, once again, if you had some email input that we're gonna validate email and you might say, yes, you gotta give us an email and yes, it needs to be a valid email. And then if you need to do things like this needs to be unique on this particular table, all of these things are available to you. Okay? And then finally, in the event that you need to selectively configure what the validation error message is itself,

to selectively configure what the validation error message is itself, you can do so right here. Cool. So finally, here's the last thing I'm gonna leave you with. If I were to switch back to my controller, well now we have a dedicated form request class for storing an idea. But what about updating it? We need validation here as well. So this is where you need to decide, well,

But what about updating it? We need validation here as well. So this is where you need to decide, well, does it make sense to create two form request classes, one for storing and one for updating? And often the answer is yes, specifically because sometimes when you're updating an existing record, the validation rules will be different than when you're creating it for the first time. Uh, so that's something to keep in mind. If they will not be different though, then you are free

Uh, so that's something to keep in mind. If they will not be different though, then you are free to uh, basically share that request class and those situations. I would do something like this. I might rename this to simply idea request. All right? Then if I switch back to my controller within the store action, I will request that. And then within the update action we will do the exact

I will request that. And then within the update action we will do the exact same thing and I can remove this entirely. So yeah, once again, here's your metric. If the validation for storing and updating is identical, then share the request. Uh, otherwise, if they have their own special validation rules, then split them up as we did there. You'll have a store idea request and then an update idea request, uh, class.

You'll have a store idea request and then an update idea request, uh, class. Uh, so if we test this out, let's come back. Um, let's go to the homepage, build a boat, we're gonna edit this. Let's fail validation. Now notice in this case, we're not gonna see anything, but it did redirect back so we know that it's working. So yeah, well, once again, if I were to come back to Edit Blade, because we have that form component

So yeah, well, once again, if I were to come back to Edit Blade, because we have that form component that we created in the last episode, it's really simple, right? I could do something like this. Give me the form, error for description, come back, try it again. Update. And now, yeah, you can see how flexible and easy that is to reach for. Alright, so that's validation at least

and easy that is to reach for. Alright, so that's validation at least to get you started in the next episode. We'll keep going.