تماشای این درس نیاز به اشتراک حرفه‌ای دارد.

Setting Up Sass CSS1:34

margin right of 1m or something like that, I think that will look better. Okay, so let's do this. Now, what do we have going on for CSS in this series? Have we done anything yet? So again, this is the boilerplate that Laravel provides for us, you can modify or remove any of this. And you're kind of expected to. But anyways, yeah, we haven't done anything yet. So I'm going to import a simple app.css file. And then if we go to our gulpfile.js, we're going to use Sass. And you can see we're looking for app.scss. So if we go in here, yeah, let's get started. So why don't we do list-group-item. And then if there's a label within it, yeah, we're just going to set a margin right of 1m. Okay, so I don't think we've installed any of our dependencies just yet. So let's do that. But I'm going to go ahead and pull in a pre-release of Elixir. Very likely by the time you're watching this, you'll see something like this in your package.json.

just yet. So let's do that. But I'm going to go ahead and pull in a pre release of elixir. Very likely by the time you're watching this, you'll see something like this in your package.json file. But in my case, we're not quite there yet. So I will grab the pre release. And I think we're good here. So npm install and give that just a minute. Okay, great. So I think we're all set to go. And by the way, let me quickly switch to a different profile here. So let's run gulp and compile that all down. Great. Oh, quick little tip, by the way, if you do gulp --silent, it will get rid of any of the timestamps. So if you just want a little table here, that's an option for you. Okay, but anyways, if we come back and refresh, it should be reflected and it is. Okay, thanks for sticking with me on that. So anyways, let's get back on task. When a User submits a community link, if the link has already been previously submitted by somebody

Handling Duplicate Links3:08

and it is. Okay, thanks for sticking with me on that. So anyways, let's get back on task. When a User submits a community link, if the link has already been previously submitted by somebody else, we will not add a new row, but instead touch the timestamps so that, for example, in this case, this one would jump to the very top. And I think that's fair. Here's how I think we will tackle this. So we're going to go to our CommunityLinksController. Here's the store method that we've been working on. So when I call the contribute method, here's what we have right now. By the way, let me add doc blocks for this. It's kind of driving me crazy. Mark the community link as approved. Okay, but anyways, when we call contribute, you give it an array of attributes. We fill up the model and we persist it. But it sounds like we first need to check, well, is there a submission that already has that link? So something like this, maybe. If this has already been submitted,

model and we persist it. But it sounds like we first need to check, well, is there a submission that already has that link? So something like this, maybe. If this has already been submitted, we're just going to speak it out and that will be the method name. And we're going to send through the link. So if this link has already been submitted, then, well, how do we fetch it? We could do this in two ways. One, this could return a Boolean, or it could return the model itself, in which case you could do something like existing->touch() and then save() that here. So yeah, really, either one works. Why don't we do this one? So I'm going to create the method. And how can we determine if we have a record of that link? Simple enough. Return static::where('link', '=', $link) and give me the first() result. Now, we're going to keep it simple like this, but you might find that you want to expand upon this where maybe you cut off any

the link is equal to the link and give me the first result. Now, we're going to keep it simple like this, but you might find that you want to expand upon this where maybe you cut off any hash values in the address bar or maybe anything in the query string. I don't know. It's up to you. In this case, it's very simple. If there's a link, google.com, and then somebody submits another link to google.com, we'll consider that a match. But yeah, just consider that you might want to filter it a bit more in real life. Okay, let's add our doc block. Determine if the link has already been submitted. And the link will be a string. Okay, so if we go back to where we were, if we found a record that includes that link, we'll save it as an existing model. And then I'm just going to touch the timestamps. And if you're not familiar with this method, let's check it out. touch. Yeah, you can see here, all it does is it bumps the timestamps and then persists it. That's it.

Testing Timestamp Touch6:23

that's going to go wrong. But let's just see it in action. My great article. Okay, so if I contribute that link, it should fail validation, right? Because we updated that a while ago. And I think I noted that we may change it in the future. So all we're going to do here is make the link no longer unique. That's fine. Because if it's not unique, all we're going to do is bump the timestamps. Alright, so let's give it another run. And hopefully, what will happen is actually let's see this in action. Let's do php artisan tinker app community link, we should have three. Right now all I have in the table is the approved ones. Okay, so yeah, here it is. So we're going to resubmit this link. And if it went properly, the timestamps should be bumped. So it's July 12. At the time of this recording. Yeah, we expect to see this update from July 11. Alright, contribute the link. And now if we run it again, there you go. So that was kind of quick to see if we come up

Exceptions vs Alternatives9:29

submitted. Now, when it comes to things like this, developers don't really agree just yet. So some would say, never ever throw an exception unless it truly is something that you did not expect to have happen. So if it's something that you think could and will happen in some cases, not when you throw an exception. Other people like to throw exceptions in situations like this, to indicate something that happened, so that you can send it up the chain and handle it. You know what, I don't have a huge opinion on this one. I can kind of see both sides. In this case, here's how this would look. If this has already been submitted, just touch the timestamps, and then throw a new Exception that we would create CommunityLinkAlreadySubmittedException. Yeah, that's basically the form it would take. So you throw an Exception, and then within your controller, you catch that Exception. And then that way, maybe you could

Yeah, that's basically the form it would take. So you throw an Exception, and then within your controller, you catch that exception. And then that way, maybe you could flash an overlay that has a title of something like, that link has already been submitted. And then the body will be, how about, will instead bump the timestamps, and bring that link back to the top. Thanks. So now, this junk right here would go within your try. So let's create this class within the exceptions folder, CommunityLinkAlreadySubmitted. And that will extend Exception. Okay, so now if we come back, we need to make sure that we import that class at the very top. And then next within our CommunityLink class, we have to throw this and import the class as well. Okay, so let me update my PHP docs. And I think this option should work. So let's go over it one more time. Try to have the user

we're not going to do this approach. But when special circumstance, yeah, for example, here is where you could do your custom flash message, and then maybe return back or do whatever you want to do there. So that's kind of a cool approach. I've used this one before. I think I use it at Laracasts for the SessionsController, in fact, to determine how we want to redirect and flash and all that stuff. So recap, you pass a reference to the current object, then you accept the caller. And then based upon whatever you need to do, you send a message back to that caller. And then the caller can once again, take over and handle whatever it needs to do. So that's a second option. Let's get rid of all this and do a couple steps. Okay, so that would be an option. A third option would be to maybe return like a response object. So something like return new Thing that happened or even a simple primitive object like status is special thing,

be an option. A third option would be to maybe return like a response object. So something like return new ThingThatHappened or even a simple primitive object like status is specialThing, you know, and then you could check that status in the controller and determine which flash message to use. That would be an option. What else? You could also, let's see, back to the contribute method, you could take this check and pull it out of the method, and then call it from the controller. So this would work. Just be careful about it, making your controller that much more muddy. So yeah, like I said, so many different options, developers don't agree on anything. So why don't you decide which one you like and leave a comment. Or if you have a different approach altogether, that would be cool to see as well. Okay, so to finish up, why don't we do one final thing. If you want to leave all this logic in the controller, I think it's honestly

Creating Form Request14:24

approach altogether, that would be cool to see as well. Okay, so to finish up, why don't we do one final thing. If you want to leave all this logic in the controller, I think it's honestly fine. It's mostly controller specific stuff beyond this. Everything else is simple form validation, and then flashing, and then a redirect. So really, it's pretty simple. But here's another option. If you just want to play around, if I run php artisan, we could make a special form request. And if you think about it, form requests in Laravel are basically just form objects, just the basic form object pattern. So why don't we try this, create a request. And then what does this represent? We'll call this CommunityLinkForm. And now that's going to be created with app/Http/Requests/CommunityLinkForm.php. Okay, so now think of this as the representation of a form, it'll be responsible for validating

And now that's going to be created with an app/Http/Requests/CommunityLinkForm. Okay, so now think of this as the representation of a form, it'll be responsible for validating and persisting the form. So the rules, well, we can just grab those from up here. So come back, and I will paste that in there. Okay, so right off the bat, we can get rid of the validation part entirely, and then update this to CommunityLinkForm. And if you didn't see that got imported at the top. Next, we can either take everything if you want. For example, let me show you. Okay, so let's add a method here called persist. This is where we persist the form. So if you wanted, you could basically take all of this and put it in here. And then you would do something along the lines of this->form->persist. Or in fact, rather than calling it request, rename this to form. And now that seems a little more readable,

And then you would do something along the lines of this request persist. Or in fact, rather than calling it request, rename this to form. And now that seems a little more readable, we're going to persist the form and then redirect back. Now only if you need to, you can drill down and figure out if the user is authorized, what the validation rules are, and how we go about persisting it. Okay, so that would be an option. Another option is you take the flash stuff, and you keep that in the controller, where arguably it most belongs. And then you take only the persist specific logic like this, and you keep it in here. Alright, so that's going to accept the attributes. Let's see what this looks like. I'm kind of doing this off the cuff. Attributes. And then this junk we have here, that's going to come back. And now we will try to persist the form. Yeah, so with this approach, we take any validation,

Attributes. And then this junk we have here, that's going to come back. And now we will try to persist the form. Yeah, so with this approach, we take any validation, and we put it into this FormRequest. And let me reformat real quick. Next, we take whatever logic you use to actually persist the form, and you put it in there as well. And now the controller itself is almost exclusively responsible for just flashing a couple messages and then redirecting somewhere. So that's what I mean when I say in Laravel, these custom request classes you can create. Yes, they're good for validation and stuff like that. But you can also, if you want, think of them as simple form objects. So let's do this. Actually, you know what? We don't need the attributes, of course, because we have the FormRequest. So we could say, give me all. Because remember, the way this works is this inherits from the Request class. So that means here, yeah, we can

attributes, of course, because we have the FormRequest. So we could say, give me all. Because remember, the way this works is this inherits from the Request class. So that means here, yeah, we can reference this all, and it's just like doing request()->all() within your controller. Yeah, so we don't even need that. So let's add our doc blocks. Persist the CommunityLinkSubmissionForm. And why don't we put this on its own line? And then import this class. Anyways, yeah, in some situations, you might find that this is a much cleaner approach. When the user submits the form, we will accept a CommunityLinkForm object that we will try to persist. And then we just determine which flash message to display and redirect back. And I won't bother showing you this in the browser, but trust me, it all works. Okay, that'll do it for this lesson. I hope you learned a couple things. I'll see you in the next video.

دوست دارید گاهی خبرهای Laracasts را ایمیل کنیم؟