 All right, so I think we can start. So this session is going to be about Symphony 2, as you might in fear from the title, and about a few other selected topics I believe are important for today's PHP developers, PHP and Drupal developers, of course. So before we start, allow me to introduce myself. My name is Claudio. I've got six years of experience in PHP development, mostly divided between Italy and France, even though lately I'm shifting toward Germany, where I founded with other five people, a company called Agavee. Unfortunately, we don't have any fusion announcement to do, but besides that, I'm also one of the founders of the Drupal-Itali Association, which is organizing events about Drupal in Italy since 2009. I believe it's enough about me. So let's start by trying to answer the probably most important question. So what is this Symphony 2 thing that everybody is keep talking about lately? So first of all, and that's probably the part I prefer the most, Symphony 2 is a set of standalone decoupled and cohesive components that are built, leveraging the latest feature introduced with PHP 5.3, namely the namespaces. And it has been built in order to be as reusable as possible, and each component has been designed to not need any other dependency. So in order to better understand how this work, we have to go back to year 2006 when the development, well, the design phase started. And yeah, when Fabian Potentier, the project leader, which was already shipping Symphony version 1, noticed that all the frameworks and products in the PHP world basically had a problem. They weren't interoperable at all. So if we think of Symphony 1 or even Drupal, it wasn't that easy to pick, for instance, the HUC system, just to name one, and reuse it wherever we needed without feeling great pain. So it started to design this set of components and the framework with this idea in mind to be as much as interoperable as possible. And today, with so many products that are starting using the Symphony components and Drupal being just one of them, we see the results of that shifting approach before that we had just vertical monolithic frameworks that were hard to reuse. Other than being a set of components, most clearly, Symphony ships a full-stock web framework that is probably what the people mostly expect when we're talking about it. So it provides additional features, such as the bundles, the bundle system, and the glue between the different components and some noticeable libraries, such as Twig, or Aceric, or Monologue, and stuff like that. So it provides a better user experience for the developer so that we can start developing faster. The last thing it's worth noticing about Symphony 2 is that, well, unlike the other frameworks that mostly implement the MVC framework, the focus has been put on the HTTP specification, on the HTTP protocol, so that it's more correct to call it a request response framework instead of an MVC framework, even though Symphony 2 provides a controller and views natively while relies on external libraries for the mold apart. But the most important thing is that it is not built around the MVC pattern while it's tried to stick as much as it can to the HTTP specification. Yeah, clearly, Symphony 2 tries not to reinvain the wheel again and again, so it uses the standards as much as we can, as much as it can. And so other than HTTP, which is heavily relied upon, for instance, for caching, Symphony doesn't provide a caching system, an application caching system. It relies on HTTP cache. It also uses other standards, such as an Java RFC for the form validation. And clearly promotes best practices, which we are going to see in a little while, at least a few. So there are not just the best practices. Clearly, all the developers outside of this room sometimes had a few bad habits that I briefly described here, such as cod duplication or bad naming for variables, classes and function and stuff like that, not mentioning the tight coupling between the pieces of our code, such as classes or function, that brought the code to be unmaintainable and unreliable and very hard to test. But I'm not here to talk about the bad stuff because I'd like to focus a bit on a few class design principles that are general or are not related directly to Symphony itself, but that can be used anywhere. But of course, being general, that can be applied to Symphony too as well. So the first one is the single responsibility principle that basically states that every class should have a single one and only one single responsibility and fully encapsulate it. I think it makes quite sense because the more we strive to localize the changes in our code, the less we tend to have bugs or unpredictable behaviors. So yeah, trying to stick to this principle will likely reduce the risk of ripple effects and produce more responsible code. Robert Martin, if this name doesn't ring a bell, I suggest you to look for it on the internet, which is one of the fathers of the design patterns, identifies this as the reason for a change. So each class should just have one reason for a change. I better describe that with an example. It's very simple. I use this mode of interface to describe how this seven lines of code violates the single responsibility principle. Even though the interface looks reasonable, it's pretty simple and straightforward. We can identify two different responsibilities here. Basically, the connection management and data communication. So if you want to follow this principle and try to achieve less ripple effects and stuff, we should try to split this interface into separate ones, each one dealing with its own specific responsibility. So the second one is the open-close principle. As Drupal developers, I think we are all used to this principle, even though in other terms. Basically, it says that software entities should be open for extension but closed for modification. If don't hack the core, basically, sounds like this principle in a way, even though it's not a class. But it's easy to find the similarity between the two principles because we don't want to reduce the reliability and maintainability of our server code. In this case, client and server are, imagine them as PHP classes, the server being a Facebook API library. So whenever we use a firewall, we should pay the license. So whenever we use some server code, we don't want to need to hack it in order to achieve the function that we need. We want it to be designed to be extensible. The third principle called the list of substitution principles probably the hardest one to grasp because it has subtle effects on real code that are quite hard to grasp. Basically, it says that any parent type should be replaceable with a child type without affecting the correctness of the program. This seems reasonable, but it doesn't suffice to rely on the syntactic contract that we put in place when defining interface and then abstract classes and this kind of stuff because it's a semantic problem. I'll show you an example to better explain that. So try to imagine we got a program that draws some shapes, rectangles and squares and we have to design some classes, a few classes for doing the task. It seems reasonable to model the problem as a base rectangle class which comes with and hide properties with the related accessory mutator methods and then derive the square class that extends the rectangle and just overrides the set width and set height methods. But if you try to run your brain common line interpreter on the function draw that's on the right column, you will see that if you pass a pure rectangle and then set width and hide and then assert that width times hide makes 20, you will get true. But whenever you pass in a square which perfectly respect the contract of this function and set width and hide again, that assertion will fail because the square behaves differently. So we see there is a flow in this design and in this case, it may be quite easy to grasp but generally speaking, even though a rectangle, sorry, a square is a rectangle, that doesn't all true in the case of square and rectangle objects. So be careful about the public behaviors of your API and try to make them respect it in order to conform to this principle. It could lead to quite hard bugs, quite hard to debug problems. And moreover, it's not easy to always apply it. The fourth is the interface segregation principle and basically states that smaller specialized interfaces are better than a big one. This is quite simple to understand also because again, it's a matter of reducing the code that we need to modify or to interact with. For instance, when we need to instantiate a printer and it does just have to print, there is no need for a scanner effects function in it that might bring problems. It's better to separate. This is actually a real life example where that goes back many years from now where Bob Martin, I mentioned before, went to Xerox to try to solve the problem they had at the time because their software became so big and took so much time to compile and be tested that they had to find a solution. And that was what he proposed them. And now the dependency inversion principle, the last one. Basically, we were used to a kind of architecture that basically made higher level in the technology stack to rely on the lower ones. So for instance, a library relying on a lower level one. That caused a big coupling between the two layers that made almost impossible for the high level layer to change the lower level one. The dependency inversion principle tries to address this problem by inverting actually the dependency between the two layers so that it's not the higher level that depends on the lower one while it's the opposite. So the component A package, for instance, defines a service that the lower level component should implement in order to provide the service that's needed. Again, here's an example. Let's say that we have a vehicle that clearly uses tires for moving. We have this class, it's very simple, where the vehicle instantiates four tires. And then we have the class tire that provides a diameter and that's it. So here we see that the vehicle class, which is our higher level layer, strictly requires the lower one to exist, to function basically. And that's not good because we can't easily change the tires in the vehicle without hacking, without changing the code of the vehicle. And that's not what we want to achieve because it makes code harder to maintain and even less testable. So this is the same problem where we inverted the dependencies. So now the component A, the higher one, which is the vehicle, defines a contract called abstract tire. So it basically says, OK, in order for me to function, I need a tire and it should behave like that. So we are free to provide any kind of lower level kind of tire by just implementing, by respecting that contract, so in this case, implementing that abstract class. And this brings much more flexibility and makes code way easier to test and way more reliable. So we've seen these principles and some of them are already implemented in symphony. Most notably, the dependency inversion principle is what it backs the service container, which we are going to see in a few moments. But before that, let's say you look at a class loader. So this is a very important component that not because of its implementation, but because of the conventions behind it. Not too much time ago, a convention called PSR0 emerged from a working group, a PHP working group. Basically, there are some representative from various framework Drupals included. So they agreed on a way to load, outload classes. It's pretty simple. It does have two different conventions, one for namespace classes and one for older underscore namespace classes that we can see there. So for instance, whenever we need to instantiate a symphony core request object, the class loader will intercept that request. So basically, when it's made through the SPL outload register that takes care of this task. So it takes the name of the function of the, it takes the fully qualified domain name of the class, converts it into a path, basically just reversing the slash in this case and, you know, prepending a path for the vendor library and try to require it. Same thing applies for the underscore namespace classes. It just converts the underscores to slashes. And that was like Zen one was already working. So this way, we will get rid of any required ones in our code. So it would be way easier to handle the class dependencies in our project. And at the same time, we will get lazy loading, which means that for a given execution path, we won't need to load the hell out of everything. But we will just load the class that are used for that given execution path. Moreover, since probably more or less all the biggest frameworks are already shifted to PSR0, we've got a way better interoperability in that we just need the classes to use this convention. And any class loader that is compatible with PSR0 will be able to load them so that we can pick a few classes from the project and also load them without any problem. And now the big superstar. So the service container, before defining what a service container is, I think we should define what a service itself is. Well, basically it's nothing but a PHP class, a PHP object, which basically performs a global task, such a mailer or a DB instruction layer or a templating system whatsoever. So a mailer could be a service, a Swift mailer, for instance. But a specific email message won't be a service. So it has this global property if you want to try to define it. And the service container is nothing but a glorified array, basically, that centralizes and standardizes the way these objects and services are constructed, are built inside our application. So basically it takes care of the instantiation and the configuration of these services. Well, actually, the configuration is what we need to do in order to make the service container to work. But that's it. Whenever we will need anything, any service, the mail or, again, the DB abstraction layer, we will just ask the container to give them to us and we're ready to use it. You will care about configuring it and instantiate it. We can see it as a sort of a satellite orbiting around our application, which is sending the needed dependencies when we are asking to do so. So here is some code I borrowed from the Drupal 8 branch. And I modified it a little bit. This is to show how a service container is working. Basically, we just need to instantiate a container and then we're ready to go. We can set parameters such as the config storage option array, where we put the parameters for our connection. And then we can register a service by giving in an ID and then a class. So config.storage is the ID of our service, while Drupal's backslashcore, backslash, config, backslash, that way storage will be the class that represents that service. Other than that, we can pass arguments to its constructor. In this case, we have the config storage option we defined a few lines before. And or we can call methods on it, such as, I don't know, a flag. Finally, with just invoking the get method and the ID of the service, we can get that service and start using it. It's just as simple as that. This is, again, borrowed by the Drupal 8 core code. And basically, it's the way I think the container will be fetched. I'm not sure about that, actually. Anyway, the only thing I would like to note in the end is that it's best not to use the container for everything, basically, to pass it around as crazy. Because in that case, our code will be coupled with that specific instance of the container. And thus, in validating a bit all the decoupling we are trying to achieve with it. Another component is the event dispatcher, which is nothing but an implementation of the observer pattern. We already got used to it, for instance, think, well, the uke system and even dispatcher can be seen as an object-oriented version of the uke system in a way. Or think about JavaScript events. This is more or less the same thing. We just define an event dispatcher and a valid PHP callable, and we attach it to a specific event, in this case, foo.bar. And whenever we need it, we can fire that event, and the callable will respond. And in this case, log a warning on the database. So this is one of the most important component in the symphony environment. And basically, it's a library that replaces the PHP global variables and functions and provides an object-oriented API that basically is modeled after the HTTP specification again. Besides being object-oriented, it means that we've got an easier way to test this kind of call or to mock request or response, which is very great for testing. And moreover, it provides a higher level of abstraction that is hiding a few tricky edge cases when handling HTTP connections. Using it is as simple as the other components in that we can just create a request object by invoking the static create from global's function meter to in the request class. And then we can start using it. We can access any kind of property from either is to create parameters and stuff like that. And it's also very easy to create a request from scratch for any reason we need it, basically, could be for testing purposes. Same thing applies for the response. We can create a new response and then check that it's compliant with the request that we received and then send it. So it's a way better implementation of how HTTP works than the one we can have in native PHP, which got global variables, strange name functions, and stuff like that. And finally, the HTTP kernel is the very core of Symphony 2. As I mentioned before, Symphony is considered a request response framework. And this very simple interface that defines just one method is the proof of what I had said before. So basically, this interface states that each and every request that is received should be then converted into a response by using any kind of PHP callable. And that is also why this framework is not necessarily bound to the MVC model because we might even not use a controller. We can use just a function as we prefer. So it is so important that if you see it has been marked with an API tag that ensure that for each subversion of Symphony 2, it won't change ever for any reason. This is how the default implementation works. And basically, we see that whenever we receive a request, event is fired. And if any listener is returning a response, then we skip all the workflow in the middle and just return that response. But before that, a response event is fired. And then the response is returned. Every time an event is fired, we have the opportunity to add a listener and modify the specific data that is bound to that event. For instance, when we have a request event fired, we can add or remove either and stuff like that. And in the same way, we can change the response how we like it. So if no listener return a request, then the routing system comes in, in the case of Symphony, and tries to resolve that request to a controller, so basically tries to associate that request to a specific controller. If a controller is found, a controller event is fired again, so we have the opportunity to change it. And then the arguments are resolved too. And finally, the controller is called. So as we saw, theoretically, the controller should return a response because the contract we've seen before states that. But in case it doesn't, the view layer intervenes and tries to transform the result of the controller into an actual response object. In other words, if a controller doesn't return a response, the view layer will try to get the correct view and push the values that has been returned by the controller and render that view, package it into a response, and then send it to the client. After a response has been sent, a terminate event is fired so that we have the opportunity to do some final tasks, such as logging or sending messages or emails or stuff like that. And yeah, in case an exception is thrown, Symphony will catch it, and it will fire an exception event and, again, package it into a proper response so that we can have stack trace and stuff like that. One thing worth mentioning is also the subrequest thing because in this way, as we go back here, we see that we have two constants defined in the interface for master request and subrequest. These are important for caching, basically, because, as we said before, there's no application caching. So forget about page cache or block cache or query cache or stuff like that unless you implement it. But we have a different type of caching, which is the HTTP cache. So by using subrequests, we are able to differently control the cache aspiration time or validation, and therefore differently cache the different parts of the page. And for doing that, we can use the reverse proxy that is bundled with Symphony or bring in varnish. Now, I think most of you already know it, but for those who don't, I just say that it's probably the most beautiful template engine for PHP, at least I've ever seen. It does come with a great set of features, very expressive syntax, and it does bring really good performances because, by default, it compiles the templates to PHP classes. And there is an optional C extension that allows to transparently substitute some rendering function with their C counterparts. If any of you was in Copenhagen two years ago and remember the keynote from Rasmus, who at the time suggested to improve the Drupal performances by implementing part of the rendering engine in C as a C extension, well, we got it in this case because by using Twig, we follow that suggestion by having no effort because it's already there, it's working, and it's super easy to install. As it wasn't sufficient, Twig is ridiculously easy to extend and very well documented. So in the end, it's a great boost for our view, for our presentation layer. And I haven't met anyone who ever complied about it as of now. So it does consist of three type of tags, which are the common tags, which don't do anything. Then there are the block tags that do some things such as setting variables or invoking control statements for if or whatever. And finally, there are the print tags that say something, that print something such as a string plus a variable, incatenated to a variable. So other than these three tags, there are also a lot of tags filters function and test that really make easy to develop the view layer. It's just a great pleasure. This is a very compressed example of a Twig template. And we can see on the first line a comment. And then one of the features I like the most, because it really gives a structure to our view layer, the extend tag. So basically, Twig tags are able to iterate from other Twig templates or Twig templates are able to iterate from other Twig templates. And that's just great, because it will make us to use a lot of code. So after the extends tag, we have a macro, which is nothing but a view function, where we can do more or less whatever we are able to do, even the functionalities we have in Twig. So for instance, in this case, we print a div containing a node ID. We can access an object property by using the dot notation. And if the properties are not public, the accessor will be called. So if we have, I don't know, the title attribute on a node object, which is protected, but a get title method is implemented, then Twig will automatically resolve that. Then we see filters. For instance, the title is passed through a title filter that basically uppercase the first letter of each word in the string. Or we can format dates. Or even we can implode arrays and lowercase them. Or we can invoke a function to print a slug of the node path. Then in the block body, which could be probably the only piece, the only block we actually extend from the layout, given that the layout might have a header block, which contains a standard header and the footer, then we just override the body. And we see that in this case, we loop on the nodes, which could be any PHP iterable or an array, and render the given node. There's also this nice 4L statement that in case there are no nodes, it just prints, we did not find any node, and pass it through the translation filter. So actually, the slug function does not exist in Twig. So here is how we create it. And it's that simple. We just need to extend the twig underscore extension class and define the get functions method in order that it returns an array of an array keyed, which keys are the name of the functions. And which values are the actual object that wrap the method that we need to call. So in this case, the slug function will be a twig underscore function underscore method object that refers to the slug method implementation we've got there. And then we can implement whatever function we need, this is just an example. Probably doesn't make sense, but it's just for the sake of show. So I run quite a bit, but I would like to share with you a few links that I've used for preparing this presentation, plus five books I believe are quite important, and I suggest you to read, two are PHP specific, and are about PHP objects, patterns, and practices, and the other one is about PHP refactoring. And we'll give you an overview on some interesting topics such as code smell, or how to effectively refactor PHP code, and how to keep up today. The other three are completely unrelated to PHP, but I think are useful for each developer. And they cover basically ex-unit patterns, ex-unit test patterns, and in this case, if we're using PHP unit, those concepts will apply without a problem, or test-driven development that will help us to better understand the implication of all the concepts we briefly mentioned today, and will help us apply them in practice. Because as soon as you start trying to do test-driven development, you will see how the old way of writing code is completely wrong in this new perspective. And in that case, simply to really help us to do the test-driven development. And I think this is it. I would like to ask you to rate the session. And if anybody has a question, just fire. Thank you. Anyone? You demonstrated using events in symphony? Yep. And I'm just curious. I know with JavaScript, when you do event-based development, you get the whole pattern changes. And it seems that in the Drupal universe, hooks are kind of closest to events, because you're causing things to happen that are decoupled, and I'm curious how Drupal programming may change. What's the relationship of hooks to events, and how might things change if we shift to using more events instead of hooks? Or should hooks be re-implanted in terms of events? What's the relationship? Well, I'm not sure if they are going to replace the hook system with the event dispatcher of symphony, because for sure they're going to use it because of the HTTP kernel. But I'm not sure about the implementation. So the hook system is somewhat similar to, it's probably the closest thing we have in Drupal that might remind you of this dispatcher clearly did not the same thing. So I think it just makes sense to have both side by side. Well, actually, I would rather go for a complete object oriented system. But I see that there are also, we also have to care about backward compatibility in a way and give time to people to get used to that. I wouldn't be surprised, though, if we won't be using both, I mean, we won't be using any of them, because things are changing all the time. And even the observer pattern is some people who are trying to deprecate it because it's pretty too verbose and introduces some side effects that are sort of bad for application. So I wouldn't be surprised if symphony, two point whatever will ship a different system. And therefore we will end up not using hooks and the observer pattern in the end. Welcome. OK. So any other question? Fine.