Observers within Slim 3. This works slightly different in terms of the setup than if you were actually using this inside of the Laravel framework. So first of all, I have a basic Slim 3 structure put together here.

This is the CoCourse Slender package which I'll leave a link to in the course links. I'll assume you're already set up with Eloquent and you know what you're doing with it. So let's just head over to Bootstrap and App here. You can see that I've just very roughly put the details in here and I've gone ahead and

created a capsule manager, added the connection settings, gone ahead and set this as global and I've booted up Eloquent. So if we just head over to the database, I've got a pre-created schema over here. This is just a topics table.

This is a good example for using observers because when we create a topic, we probably want the slug to be automatically generated. So we just have a title and a slug and then created and outdated that as you would expect from Eloquent.

So let's go ahead and create our model just over here and then we'll just start to look at how we would normally do this. So let's create our models folder and of course we're going to go and create a topic model inside of here.

Let's just build this out very, very quickly. This of course is going to extend the base model within Eloquent and let's pull the namespace in for this and pull the namespace in for the model as well. We'll do a little bit of setup so we'll set our fillable columns just inside of here and

that is going to be the title and the slug. So usually within the context of a Laravel application, I would create a service provider which would register a observer class. Now we can do this within Slim.

It's a little bit trickier to start playing around with service providers unless we change over Slim's default container. What we're going to do though is just take a look at the easiest and cleanest way to do this.

So for example, inside of the model, I'm going to create a public static function called boot. This will override the base boot method on the model that we've pulled in here. Now really importantly because we're overriding this, the first thing that we want to do is

just go ahead and boot up the parent and this isn't going to be much different. So if we head over to the home controller just to test this out, let's go ahead and create a new topic in here and of course the job here is to assign a title but have the slug automatically generated for us.

So let's pull the namespace in for this, head over to here and give that a refresh and sure enough we should now see that topic over in here, however it doesn't have a slug just yet. So the next thing we want to do is inside of here say, well when we have a creating

method called, so when we're creating a particular model, then we want to intervene using this closure in here and we want to go ahead and extract out the topic that's being created and then we want to do something with it. So in this case I want to assign to the slug and in this case I'm just going to say some

slug but you could use a package to generate that or whatever you wanted to do. So this should work and in the context of a Laravel application this would work. If I give this a refresh and check the database, notice that the slug still hasn't been saved. We've set everything up correctly and this should technically work.

Now the reason it's not working is we haven't added in our event dispatcher when we set up Eloquent and this is a key point of doing this. So let's just head over to our capsule manager here and let's look for dispatcher and you can see here we can set and get an event dispatcher.

Now normally this would all happen automatically within the Laravel framework but we're going to have to call this and manually pass in our dispatcher when we set this up and this is just about as easy as it gets. Now where is the event dispatcher coming from?

Well this is coming from the Illuminate events part of the Illuminate framework. So we can go ahead and pull this down with Composer and we can pull in a new instance of this dispatcher and this will handle all of them events nicely for us. So if we just do a Composer require on Illuminate events, wait for this to finish and we can

new it up and pass it into that method. So now that's pulled in, let's come over and create a new dispatcher over here. Go ahead and pull the namespace in for this either inline or at the top and in this case it's Illuminate events dispatcher as we've already seen.

Now what's going to happen is if we come over to our topic and we say kill the page here and just output anything, you'll notice that this will actually work now when we try and refresh and create an instance of that model. And in fact the code that we already have here to go ahead and assign the slug is also

going to work. So if I just give this a refresh, come over to the database, sure enough that is now working. So a really nice easy way to get events set up. But we're not quite going to stop here because if for example you had when you wanted to

update a particular model, you wanted to do something, so you could say updating or you could say saving, whatever you wanted to say. Now this gets a little bit messy. So what I prefer to do is either over in the models folder or the main directory, I'm going

to go ahead and create an observers folder and this is going to contain our topic observer. And instead of this being a long list of closures, it's going to be just a class that holds lots of methods. So let's create out this topic observer inside of here and look at a slightly different way

to set this up. This is just going to be a plain class. It doesn't need to extend anything. If we pull the namespace in for this and we go ahead and essentially copy over what we've

done inside of here, we just give a method name of creating. That's going to do exactly the same thing once we've set this up. So when we say creating, all we do is we get the topic into here. Good idea at this point to type in this so you know exactly what's being passed in so

we can pull the namespace in for that as well. And that's going to have exactly the same effect but of course we need to set this up slightly differently. To do this we use the observe method and then we just go ahead and pass in a new topic observer

and that's going to go ahead and handle that for us. And of course you can pass dependencies into here if you need to but it's not really usual that you'll need to do that. So let's just change this around so we know that that is definitely working.

Give this a refresh over to the database and sure enough that is working also. Now you might not want to over in each model override the boot method to go ahead and do this. So of course what you can do rather than statically accessing the model and using that observe

method, you can do this pretty much anywhere else in your application. So for example you might have inside of Bootstrap an app all of your events set up here or you could require this in as a separate file and have all of your listeners inside of there. So let's just do it down here for now just to keep things simple but you can choose the

structure however you like. So let's grab this and get rid of this because we're no longer going to do this inside the model and let's pop this in here but of course we can't use static within the context of a flat file so we're going to reference the model name instead and of course pull the

namespace in for that and make sure that we pull the namespace in for the topic observer as well. So what that's going to do is register that observer, in this case having lots of different methods all doing slightly different things depending on the action and this is going

to work in exactly the same way. So there you go. You now know how to go ahead and add the event dispatcher to the capsule manager and go ahead and observe either like this or directly within each of your models.