 Okay, welcome. How are you? Great. Okay, I have three people here. So welcome to my presentation. I am the last one. Hopefully it would be interesting. If you have any questions, feel free to ask. There is a mic over there. So just get up and ask your question. Today, I'm going to talk about symphony. A little bit about Drupal, but you have to know that I'm not a Drupalist at all. I tried it for Drupal version eight, and it was like very difficult to me because I'm from symphony and without all the objects and so on with the hooks and it was weird for me. So yeah, I'm going to talk about both symphony and Drupal. Who am I? I'm Sarah. Nice to meet you. I'm working for Sensual Labs. Of course, during the whole day, everybody talked about Sensual Labs in here, but especially I'm working on Sensual Labs University. If you want to know more about this structure, just come see me. I will be around. Actually, I will be at the meetup. I will talk about that later. I'm a trainer and a developer, and I love to share. That's why I'm here today. And yeah, I'm trying to contribute to symphony too as I'm sure you are doing the same with Drupal. I'm living in Paris currently. Great city. Great city because there will be the symphony come. So it will be in December and it will be at a special place called the Folie Berger. So yeah, if you want to come, you're more than welcome. So what's the plan today? I'm going to talk about the philosophy of symphony. Then I'm going to talk a little bit about dependency injection, which is the heart of symphony, not that much because Richard did it right before me. And at the end, I will talk a little bit about templating because Javier already talked about it before. So let's begin with the philosophy. You may know that when you are doing a web application, most of the time, the protocol that you are using is HTTP, okay? When we are talking about HTTP, you will have the request, okay? Which is basically some text with the method. We have the URI and of course we have the protocol. Then we could have some headers and of course a body for the request. Then when we want to respond something, we use a response, an HTTP response, which is like you can see here. Most of the time we forget about that. But yeah, the job of symphony is basically to do that, okay? So maybe you heard that symphony is an MVC framework. Actually it's not. It's just an HTTP framework. And if you are talking about architecture, what symphony provides you actually is the view layer and the controller layer, okay? So I'm going to explain this big thing. Don't worry, it's going to be okay. We will go state by state, okay? So yeah, first the HTTP request, we just saw it before. So we have it from internet basically. And yeah, we'll receive it from, or maybe yeah, in the front controller, okay? When I'm talking about the front controller, if you are a symphony developer, I'm talking about the app.php. In Drupal is the index.php, okay? And the job of this front controller is basically to turn the request that comes from the HTTP protocol to an object, okay? Which is part of the HTTP foundation. So yeah, and after that, we need to communicate with the HTTP kernel. We'll see that right after. So two components involved here, which are used by Drupal first. First, the HTTP foundation, which is an abstraction of the request and the response that we know from the HTTP protocol. And we have the HTTP kernel, which has one responsibility, which is turning a response in a request to a response, okay? So again, in Drupal, it's just the index.php. In here, it's just Drupal version eight I got for myself to try it, okay? And in there, we can see those lines, especially the one, the biggest one, which is getting a request on the right side, on the right side and turning it to a response, okay? So the first line is basically creating the request from the globals. When we're talking about the globals, of course, we're talking about the global variable of PHP, dollar underscore get, dollar underscore post and so on to get the object. And then, yeah, turning it to a response, then send it, basically, it's just an echo with a header and that's it. Now we can go further with this time, the routing component. And the routing component here has one responsibility, actually it has two, but we are going just to talk about this one, is basically to map a URL to a set of parameters. That's basically what I'm showing you right above or underneath. So we have the name of the root. We have the URI that we want to match with a colable, actually. When in here, you see that it's a controller. So the special underscore controller is very important because it's an attribute that is used by the routing component, saying, okay, you are going to call this controller with this special method, which is index action, okay? And yeah, just for the record, the second responsibility of the routing component is for generating URLs, okay? So in Drupal, we have this file that we need to complete and we have to follow this convention, which is the name of the module, dot routing dot channel, okay? You will see that all the configuration is in YAML. Maybe you already know that, but it was a premiere for me because all the time for the routing in symphony, I'm always using the annotations, so it was new for me. Okay, now we can go further in our kind of eye. And now it's about calling a controller, of course, because remember, the responsibility of the routing component is basically mapping a URI to a set of parameters, which is underscore controller, which is my controller. And of course, I have my model and view because the controller has some responsibilities, which is making sure that the communication between the model and the view is done correctly, okay? And of course, a controller has one main responsibility, which is returning a response, okay? Remember, the philosophy of symphony is getting a request and answer a response. So basically you have this kind of code, okay? And yeah, we don't have much. We're just returning a response with some content, okay? I will show you that after, when we will talk about templating, that in Drupal, actually, you don't have to answer a response, to return a response. It's an array and when I discussed with some Drupalists, it's always about array in Drupal, so you're not lost. Okay, so let's go further this time. And yeah, we have just one job here, returning an HTTP foundation response. And yeah, we have the HTTP response and that's it. This is the main goal of symphony. That's why Drupal used HTTP foundation, HTTP kernel, some of the routing components. But there is more, okay? Just wait for it. It's the event system. And I know that you are used to hooks and it looks like hooks, but it's not the same because it's not in a script with some functions and so on, it's all objects. So, let me explain you. The event dispatcher component helps you to easily decouple code and plug in new features, okay? That way, you're not obliged to iterate from any object to add new features, okay? So, two main concepts here. We have the dispatching of an event. So, let's say, okay, something happened and the second concept is basically to listen or subscribe to that event, okay? So, the event. It's an object, again, and in there, you just have to store some information that you need in your listeners, okay? That way, from listeners to listeners, you can grab some information and pass it to the next one, okay? The listener, it's just a valid PHP collaboration and most of the time, it will be, of course, an object. And yeah, when I say collaboration, it could be anything that you know in PHP which are a function name, an instance method, or a static method, or a closure, or a lambda function, okay? Maybe you heard about this difference as I'm doing a lot of training. Most of the time, people are asking, what is the difference between an event listener and an event subscriber? A matter of taste, actually, okay? So, let me show you some code, don't be afraid. In here, I'm showing you an event subscriber and basically, we have a class that has to implement the event subscriber interface and you see that this interface is coming from the event dispatcher component, of course, okay? As we're implementing an interface, there is some contract to fulfill and the contract is to implement the static method called get subscribed events. In there, we have to return an array which is the name of the event we are listening to and we have also the method that we need to call. The method we need to call is, of course, in the same class of the listener, okay? I'm not showing this to you because you may know that it's public function in here for the article.save, it will be on insert article, okay? The little number right next to the method is the priority. So, the highest priority you have, the higher, the sooner the listener will be executed, okay? In here, I can see, when I'm reading this, that for the event article.save, I have two method that will be called, okay? The priority is five than 10. So, basically, on insert article will be executed before the on update article, okay? We have also the article.delete and it's another event and, of course, we will call the method ondelete article which is priority zero. Actually, by default, it's priority zero, okay? In there, as you can see, when you are opening the subscriber, you already know which events you are subscribing to, what is the priority and, of course, which method you are going to execute, okay? Remind this for the listener after. You have a second step to fulfill which is adding the subscriber to the dispatcher. I didn't tell you that, actually, the event system is driven by the event dispatcher, of course. So, the event dispatcher is basically just an object and on this, you just have to call the method add subscriber. Of course, in Drupal, you don't have to do this. It's only if you are doing, let's say, an application, a plain old PHP application and you are just using the event dispatcher component. If you are doing that, you're obliged to instantiate the event dispatcher, then add the subscriber, okay? We'll see after when we'll be, yeah, in one or two slides. Okay, we know about subscriber. Now, what is the difference with event listener? This time, the listener is also a class, of course. You can see that there is no interface to implement this time and, of course, you have to implement a method, could be anything. Most of the time, we use the own kernel request, own kernel exception, own kernel, blah, blah. Because in here, we know that it's listening. We know because we know symphony, okay? That we are listening to the kernel.request event. We'll talk about the events that are triggered by symphony. In there, I'm just doing some stuff, like making sure that I'm in the master request. When I'm talking about master request, it's basically that you could have several requests in one at one time. Let's say I want to display the page slash users, okay? And in there, I could do, when I do in there, when I say in there, it's in the controller. In the controller, I could do some things and do a forward. And when I do a forward, I'm calling basically another controller and when I'm doing that, I'm doing a sub-request and so on. I could have many requests I need, actually. So that's why, yeah, maybe you will hear about the request stack, maybe. Okay, so I'm just making sure that I'm the beginning of the stack of the request. Otherwise, I'm returning and it does nothing, okay? After that, I'm just getting some attributes from the request. You can see that as I said before, in the event, I have some information in there. I just make sure that I have the request and basically symphony to care about setting the request at some point. So I just get it, I get some attributes which is underscore file in there. And setting a response. If I'm setting a response in here, it's just saying, okay, you are going to finish all the things you wanted to do and go back to the front controller and then send the request as you know the HTTP response, okay? So basically what you can see here is that in your events, event subscriber, event listener, you can set a response whenever you want actually, okay? So you do this class, you do this method and the second step is basically to add the listener to your dispatcher, like the subscriber, but this time it's the method add listener. In there, you can see that there are more arguments. Of course, we have the event we are listening to. In here, you can see that I'm using the constant. It's a good practice actually to use constant instead of the name of the event directly. And I'm just saying, okay, when the event will be triggered, I will, symphony has to call this class called MyListener with the method on CaneloRequest, okay? So basically the difference between the two is again, a matter of taste. I prefer the subscriber because when you open the class, you see everything you need. But you can do whatever you want and actually you may know that's about the priority. Of course, for the listener, you can put another, everything you want about the priority. At the end, symphony just do, all the subscriber becomes listeners and of course, listeners stay the listeners, okay? All right, so, yeah, I talked about events. I talked about listeners, event subscriber, event listeners. But I didn't talk about the fact that you have to trigger the events, okay? To trigger an event, it's really easy. You have to get the dispatcher, which is here. I'm instantiating the event dispatcher. Then on the, yeah, the event dispatcher, calling the method dispatch. The arguments are really easy to understand. The first one is the event. And the second one, of course, is the event which has all the information we need to make sure that in your listeners, you will have all the information you need. Easy, right? Okay, so I told you that in Drupal and in symphony actually, you don't have to do this. You have to do this only if you are using the component by itself in your PHP project. Let's say you want to migrate from an old PHP application to symphony step by step. You don't want to change everything. You can just grab a component, install it, and yeah, okay, let's say we want the event dispatcher now. Okay, so in Drupal, you just have to create a service. To create a service, you have to create a file in your module, and this file has to fulfill the, yeah, this constraint, which is the name of your module, dot services, dot channel, okay? It's at the root of your module. And in there, you can see that there is a special key services, you have to put it. It's important because it's a service. I just put after that the name of my service, which is weather.job.listener, could be anything actually. Then I'm just saying, okay, this is the class you are going to instantiate. There is maybe some arguments because my listener needs an email in the constructor. And what is very important is the tag, okay? By just saying this service has the tag event dispatcher, event subscriber, sorry. I'm just saying, okay, it's going to be a subscriber, and it will be loaded and so on, okay? So in Drupal, you just have to create the class and then just declare it as a service with the tag. Same thing for the event listener, but this time you have to put some more information, which is, which are, sorry, the event you are listening to, and the method you are going to call when the event is triggered, okay? If you have several methods in your listener, your event listener, that you want to execute when the kernel.request is triggered, you just have to add one line and one line and again, okay? In the event subscriber, of course, you don't have to do that kind of thing because everything is done in the get subscribe events studying method, okay? I talked about one event, which is kernel.request. Actually, in symphony 2.7, we have six, and yeah, it's really important to know them and when to hook your code because, yeah, you have to know that the kernel.request is the first event that is triggered. The second one is the kernel.controller, and basically it's when the router components already know which call level it has to call regarding the URI, okay? So at this point, you know which call level you have to have, so basically your controller. The kernel.view is triggered only if your controller doesn't return a response, okay? It's really useful for Drupal because of course, in your controller, you will see that you have to return an array, so of course, there is a listener listening to this kind of event to make sure that it grabs the array you're returning and make sure that it returns the right response regarding the theme and so on. The kernel.response, of course, is triggered when the response is returned, okay? So at some point, you want maybe to change the response or whatever you want, and you have the kernel.terminate, which is triggered when an exception occurred. Oh, actually, there are seven events, sorry. I forgot one, and you have the kernel.finishrequest, which is triggered only if, actually, it's useful only if you have PHP, FPM, and you will see in the documentation of symphony that basically this event is useful only to perform some action that you don't want to wait for to display the response. So let's say you want to send thousands of emails, okay? But you don't want to wait for the mailer to send all the emails to send the response to your user, okay? So you just have to hook on this event and make your logic in this listener to send all the emails, but don't forget that you need to have PHP, FPM, otherwise it's not useful at all. And yeah, the seventh, actually, is the kernel.exception, I forgot about that. And of course, it's triggered when there is an exception. And basically, you will see that when you are throwing an exception, I never tried in Drupal, but in symphony, when you are throwing an exception, you will see that there is no, there is a response, actually, because there is a listener listening to this special event making sure that it gets the type of the exception and returns the right response. When I say the right response, it could be some content with the right status code. Let's say 404 or 500 and so on, okay? So, altogether now, we have the HTTP requests. We are turning it, we are just receiving it in our front controller in the index.php. We have the HTTP kernel with the special method handle, which takes a request and has to return a response. But of course, for that, we need some controller. For this controller, it goes by the written component. In your controller, of course, you have some communication with the model layer and the view layer. At the end, we have, of course, an HTTP foundation response. Could be returned by yourself or by a listener or whatever you want. And at the end, of course, you have the HTTP response and at some point, you could have an event listener or an event subscriber, okay? Easy. Actually, if you understand that, you can, it's only useful to know where is the code. When you don't know where the things is going on because, yeah, most of the time, we'll put everything in the controller and so on. Just remember that there is some things here and there. If you know the whole thing, it will be okay. So let's talk about Drupal 8 and Symphony. A story of love, I guess. Here are the components that are used by Drupal. We saw actually the Symphony event dispatcher. We saw the HTTP foundation, of course. We saw the routing. We saw HTTP kernel and that's it. But they are the main ones, okay? Now, I'm just going to talk about the dependency injection one. So, actually, I'm just going to talk about what is the point of doing services and what is the service container, the parameters and so on. So the dependency injection component just allows you to standardize and centralize the way objects are constructed. So what I'm saying here is just that the dependency injection component is just managing the way the services, so the objects, are instantiated. So it does just new, new the class and that's it, okay? What you are going to do is some configuration to make sure that the instantiation of this class is done correctly, that's it. So three main concepts about the dependency injection component, sorry. The first one is, of course, the service container. The second one are the services, of course, and parameters. So the service container, as I said before, is just here to manage the instantiation of your classes. And when I say classes, of course, I'm talking about services. It makes sure that when you want to get a service, it gets always the same instance and it stores some parameters, that's it. So it's a big object that just makes sure that the instantiation of the classes are done very correctly. What is a service? It's not that easy to understand when you don't do services. Maybe most of the time when we are doing some logic, you are doing this in your model layer and in the model layer, you could have, let's say, a domain object, could be user, it could be address, it could be, I don't know, anything you want and you put some methods that can contain a lot of code and that's it. But a service is not the way you think. When I began with a symphony and framework and services and so on, I was like, okay, a service is just a class where I can put some logic and that's it, okay? Actually, it's not that wrong, but you just have to ask one question when you want to do a service. Does it have a state? And when we are talking about a user, an address, or I don't know, a chair and so on, it has a state, okay? So it's a domain object, it's not a service. You have to remember that a service is basically just a PHP object that can perform global task. When I say global task, it could be a mailer, a logger, something that can grab information from your database and so on, okay? That's basically what I'm saying here. And what is a parameter? It's just global configuration. So you will have just key value that you can use whenever you want if you have access to the container, okay? In Drupal, what I said before is that when you are declaring some services and parameters, you have to put it in this file, which is the name of the module, dot services, dot channel, okay? And it looks like this. We saw a little bit before about the event subscriber and event listener. In here, I'm just adding the part with the parameters, okay, and I said before, it's just key value, okay? And in your services, as you are just saying, okay, I have a parameter called weather underscore endpoint. I can use it in the services, let's say in an argument, with the person sign, okay? When you are using the special person sign, you're just saying, okay, grab it from the parameters. Easy. The add sign is just saying, okay, this special string is going to be referencing to another service, okay? So you have to know that for the argument, it could be a string, a service, it could be a collection, it could be a constant also. But in YAML, you can't use PHP constants. So, sorry. And yeah, about the tags, just a quick reminder. I don't know if I talked about that, but the tag is just a sticker saying, okay, this service is really special. You have to treat it in a different way. And as you can see here, I'm tagging the service weather job underscore listener, only because I want to make sure that it's going to be treated differently because I want to make sure that it's an event subscriber. So cold when an event is triggered, okay? About the templating. So don't worry, we're going to talk about that. Basically, in your code, you have this kind of code, okay? So in here, we are in a template called layout.tweg. And in there, you have just HTML code. What you can see is that you have kind of different things which are the block right here. I have a block title, I have a block style sheets, I have a block content, and then JavaScript. Here, if you were not at the talk of Xavier, it's basically place holders. He called it some holes. It's really nice to see because in here, you can see that basically in your HTML code, you're just putting some blocks right in there that you can actually overwrite, okay? To overwrite them, you just have to extend from the template we saw before, which is the layout.tweg, and just creating the block that are already defined in the parent. So here, I'm just doing inheritance. Of course, you can do more with templating and twig, okay? So again, I hope the presentation of Xavier will be up soon. But of course, you have a lot of documentation about that. But basically, when you are beginning with the templating part, it's mainly this. You have some four statements. You have some things to do. There is a main thing that you need to understand which are the curly brackets with the person sign which saying I'm going to do something as you may see here. As I have here the curly bracket person sign, I'm just saying, okay, you are going to do something, extend from a parent, okay? Then with the block, I'm saying, okay, you are going to take this block and override it, and so on. The double curly bracket here is just saying, I'm going to display something, okay? And of course, this variable is not coming from nowhere. It's coming from the controller, okay? So in Drupal, you have three main things to do. Yeah? The first one is the weather.module. I don't know if in Drupal 7 you had this. But in there, you have to know that you have to implement some things called hook. You know that, of course. And in there, you have just to say, okay, what is the name of the template I'm going to use for the controller I'm using. Actually, yeah, it's not the controller, it's the theme. So the key forecast is basically took from, this time I'm in the controller, and I have the hashtag theme, and it's the same name as the key I had in my array right there, okay? Then I create my template, and that's it. It works, okay? That's why I'm saying there are three steps, because yeah, of course in here, you can see that the name of the template is of course forecast, because that's what I told to the hook right here, okay? There is documentation, of course. So feel free to go there. There is, when I began with Drupal 8, it was very difficult, because the documentation is always under construction. Sometimes it works, sometimes it doesn't work, so yeah, trade out. It's a way of contributing to Drupal, and make sure that it will go out one day. But yeah, in the twig.centralabs.org, you will see all the documentation about twig, and you have to know that whole functionality of twig is not used by Drupal, okay? So you just have to try it and see. And that's it for me. If you need any training, just come see us. We have a booth. If you want to know more about Blackfire, again, come see us. And if you want to know about my cat, also, it's Lannister. He's really cute. I love him. He has a Twitter account, so feel free to follow him. And tonight, there will be a meetup, maybe you know it. I don't know if you see something. It's at the auditorium, like that. Yeah. So come, it will be awesome. There will be Fabien, which is the creator of Symphony. There will be us, Javier. So yeah, come see us. Thank you very much. Any question? It was really clear. Really nice. Okay, thank you very much.