 This is scary I Don't think I've ever spoken in front of a room this full with people sitting on the floor Welcome everyone At this symphony best practices from the trenches First of all, I apologize for my voice. I've just been ill for about three days And the worst thing that flu did was it got to my throat So I'm gonna drink a lot of water and if I sound weird you now know why My name is Stephen Coppershop. I am from the Netherlands. I Am one of the co-founders of user groups like PSP Benelux I worked at PR or was a volunteer at PFC as well here in the Netherlands. I Run a company called ingevikled for those not from the Netherlands Ingevikled is the word for complex, which is how I like my projects I've got two people working for me now we do a lot of projects mostly using symphony And my in the past I've done a lot of open source stuff with the PHP BBs and framework symphony joined in protocol or whatever stuff like that Now first of all, I want to try and get to know you guys a bit because I'm so who here has never worked with Drupal There's a couple of hands so this is exact exactly why I want to try and get to know you guys because I'm not really that familiar with the Drupal community It wasn't until Drupal started adopting symphony components that I was like oh Drupal. That's interesting So how many of you have worked with a PSP framework? Well, that's a lot of things a PSP framework that is not Drupal Still a lot of hands. That's good How many of you have worked with the next generation frameworks like Zen framework to symphony to Laravel stuff like that. That's quite a lot of hands. This is a good thing So if I'm going too fast Let me know if you don't understand anything. Let me know because I'm here to try and explain stuff to you guys If I'm going to slow also, let me know This is only the second time I'm doing this talk, so it's very important to get feedback on this talk Now I usually use the site joined in for feedback This is also because a lot of the PHP conferences use the same site to see if a talk is any good So I would kindly like to request you guys to leave any feedback on this website It can also be negative feedback as long as it's constructive Because that will help me improve this talk. This is only the second time I'm doing this So it's it's especially with a room this full. It's a bit scary So our topics for today I'm gonna I'm gonna run you through a couple of best practices for working with symphony to Now some of them are very much based on the symphony to full stack Have any of you worked with the whole symphony to full stack? Couple of them. Okay. So for those that haven't worked with the symphony to full stack yet. That's okay Some of the things that I will run through will still apply if you work with just a couple of components But some of them might not apply So one of the topics that I want to talk about is dependency injection Another one is the service layer and what is it? Symphony to documentation very important for people working with symphony project configuration, which is very much for for the full stack stuff Service configuration similar, but you can also use that when you only work with several separate components also about choosing and standardizing composer very important and Well any other stuff that could be a lot of stuff in there and if you have any specific questions I'm glad to answer them as well Let's start with a bit of history once upon a time There was symphony one and Symphony one was a full stack framework and the biggest problem with symphony one was that it was a full stack framework Because it was very hard to to try and use separate components like Drupal is doing right now that wasn't possible with symphony 1.0 Over time some of the components were separated in symphony one, but really symphony one Yeah, it was I really liked symphony one, especially for that time because it was the best framework at that point But the fact that you were really tied into symphony one into the structure that it was using It could be annoying sometimes And then at some point Symphony one disappeared. No, it didn't disappear, but symphony two was was launched and symphony two was all about Separate components all of these components were decoupled. They were they were usable On their own they were documented by themselves and you could start using all of these separate components But you could still use it all together glued together as a full stack framework Now this was a great thing because now instead of using everything in symphony. We could start using small pieces of symphony two Which was really nice Because a lot of open-source projects started using some of the components There's it. There's a lot of if you start searching for it There's a lot of open-source projects these days that use symphony two components some of them try to use everything Most of them just use a couple of components and start working with that So that's that's a bit of history the funny thing is It doesn't stop here They're already working on symphony three and stuff like that. Famiya is here somewhere not in this room, but at the conference So if you if you see him just ask him about it. It's it's interesting or read about it online. It's possible so one very important change in in symphony and Also basically in the PHP world is the usage of dependency injection. Is anyone familiar with dependency injection? That's a lot of hands. That's good thing for those that that aren't let me try to explain it a bit So basically the idea about dependency injection is that there are no hard-coded dependencies anymore in your code So that means you're not instantiating classes anymore inside your classes But instead you're just injecting them by by passing them on to the to the constructor or having separate methods for that This makes it very easy to manage and update specific classes because now if I want to replace I Don't know the implementation of sending an email from one to another library as long as the interface stays the same That's okay because I just inject it. I don't have to change the everywhere where I instantiate this class anymore Instead, I just change it in the single place where I create this class This also helps minimize the bootstrap code I I run into a lot of old legacy code bases with my work And a lot of that code means it they will have like a hundred lines of just setting up all the classes and configuring everything We abstract that away with dependency injection, there's a separate place where you do that and then you just start using them together Also, it makes it for more testable code because now because I don't have any external dependencies anymore I can if I use a database in my real Codes I can inject a mock Database class into my tests so that I can just check if the right methods are being called and if it handles the Stuff that's being returned. I don't have to actually, you know, use the whole Code tree anymore for testing I can write the test for one specific class for one specific method and just check if that method does what it's supposed to do So very simple example If I have a class foo with a public function bar Right now here. I instantiate a new instance of the coffee class So I have a coffee class defined somewhere else and I instantiate it here The problem here is if I were to Want to replace coffee with something else which right now I'm not drinking coffee. I'm drinking water That's that's going to be very hard because everywhere in my code where I'm using the coffee class I now have to change that to the water class And also the bootstrap happens here because I just instantiated it here. So that's that's also a problem Well, it's the other way around so basically this whole part I'm doing it in my class right now, and that's really a problem So what could be the solution? Well, my class coffee could implement an interface called roastable Now everything that's roastable will have the same methods And I can easily replace the coffee with something else because now my constructor will just accept A parameter I call it dollar coffee here. It could be dollar roastable But the most important thing is that I Tell my PHP that I expect something that implements roastable. So now if I create a new I don't know T is not roastable. Is it now? It's not roastable If I if I create a new espresso class As long as it implements the roastable interface which defines which methods should be there and how it's supposed to act I Will I will still be able to replace it easily And now in my constructor. I just instance or assign This a parameter to a local property So now in my bar class the only thing I need to do is return this coffee drink Which was which is the same as what I did before but that now I only have one line here instead of three Yeah, this is not really readable So this is an example of The configuration the service configuration for symphony to I'm using XML here But you can use anything in symphony XML YAML plain PHP whatever you want So basically what I'm what I'm telling symphony here is that I have a coffee class called coffee And I have this full class called fool And now I just say okay. I want to define a new service The name of that service is coffee and the class is whatever I defined here and I create a new service called fool Which is an instance of foo in this case and I pass This service the coffee service to fool so now is if I instead of coffee I want to express so the only thing I need to do is change this As long as the interface Is the same because of the fact that I type into that in my constructor So that makes it a lot easier to to define Which coffee class in this case I want So in symphony to in the full stack if you extend the standard controller or any of the other standard base controllers You can just do this get foo and That will get that from the container is actually this container get foo And that will get it from the container and then I can run bar and it does whatever I want to do So that makes my controller a lot smaller as well because I don't have to instantiate it here in the controller anymore Okay service layers. This is a Something I've been working with a lot in the past months Basically what the service layer does is it abstracts away your data store from your business logic Or it abstracts away anything from anything basically but in most cases It's it it's wherever you store your data is not important to your application. That's that's something else and you put a layer in between Most people will know this as a separation of concerns and because of the Dependency injection that I mentioned before you can very easily access these services via the service container So You could have This is the same slide. Yes So basically you would have something like this You can have a controller that calls the service layer and then the service layer Decides where to store it via the service configuration that I mentioned earlier So I could have a database my squirrel database at one point and then migrate to I don't know An API at some some point later in the project as long as I make sure that it implements the same interface I don't have to actually change any code And actually you can take this even further by abstracting Everything that's that's your application Into something separate There's a very very good talk from symphony live last year That you really can check I will publish the slides online. So you don't have to copy or write the URL But this is a really really good talk and I really really recommend watching this it is Very interesting to see how far they take it But it this is this is a really good talk It makes you think about where you put your logic in your application a lot of the logic in symphony in a lot of symphony Applications is put into the controller Which is not the place because the controller is only responsible for getting a request and returning a response And everything else should be somewhere else symphony to documentation If you work a lot with symphony to you will learn to appreciate the symphony to documentation Because it is the best starting point for your search Whenever I I don't know something for sure the first thing I do is go to symphony.com slash docs and Look it up because a lot of the questions that you have will be will be there Whether you work with the full stack or you work with a specific specific component all of the documentation is in the same place This is really useful and it's it's amazing how many people Don't don't do this as the first step Because there is a lot of good documentation there Of course The documentation isn't isn't gonna describe every single problem that you're gonna have So you can very easily Walk into a problem that you cannot solve by using the symphony documentation So The default way for doing it then for solving your problem then is Google Which will bring you to stack overflow Yes, this is this is how it works. I mean, I'm pretty sure it works the same way with Drupal You always Google for the problem and the first result in in your search will be a stack overflowing and Sometimes it doesn't really solve your problem, but it will give you the right starting point to to take it further also There's a lot of blogs People writing about symphony sometimes they will actually pop up as the second link in Google Usually it's like the first five links are stack overflow links and also This is really important if you work with symphony and you run into a problem and you solve the problem blog it yourself Because the next person is gonna hit Google and gonna find your blog and solve the problem in two minutes instead of an hour And it's really frustrating to Have to work on something in two hours for two hours and then finding out the solution is already on the internet Also the RSC channel. There's a symphony RSC channel on the free note network and there's actually a lot of localized Channels as well. I think there's one for France. There's one for the Netherlands. There's probably one for Germany There's probably more even that I don't even know of because I don't speak their language But there's a lot of localized RSC channels that you can use if you if your English isn't all that good and Then well if something is missing in the documentation you can add it yourself the documentation is also on get up So you can just write a new I don't know tutorial and send the pull request And if the pull request or if the tutorial is any good, it will probably be merged and it will be visible on the symphony website There you go get up that comes symphony symphony dash stocks It's really did easy and then I need to recommend a book this book is a really really good book It's called a year with symphony. It's written by Matthias Novak and he basically wrote about his first year of experience with symphony and he's putting a lot of he put in a lot of effort into Explaining stuff that he walked into And trying to to help other people with his experiences It's available in lean pop as a as an e-book or even as a print book I think and it's really recommended to to check this one out if you want to start with symphony Right if you work with the symphony full stack then using the right project configuration is very important You should really put everything in its right place. I've run into a couple of projects That people just either didn't use configuration at all and just hard-coded everything into their code Or they they really didn't put it into the right way So basically the the standard configuration stuff like the config files is For extensive configuration for for The more the more complex stuff, sorry In in a lot of cases where you use this configuration You just add the configuration to the config files and then parameter parameterize it. Wow. That's a good word Because there is a separate file where the parameters that are different for each of your environment are placed And most of the times those things are different in the different environments in your development environment You're not testing against a production API. You're testing against a development API or testing API stuff like that So the config file might actually have the location of the API but as a parameter and you add it into the parameters file Your routing should go into the routing file Your your security related stuff should go into the security the jumble file And then of course the parameters go into parameters of jumble All of this is being parsed by symphony if you use the full stack So everything is is basically put into one big configuration and put into the cache So that it doesn't actually have to read through all of these files and parse everything on every request Except of course if you work in the development environment because in that case It has to find changes Okay, I mentioned services before I'm gonna mention a bit more about service configuration This is a small thing I ran into. I don't know a year ago year and a half ago where There was an issue of Picking yaml or XML. I was using XML because that's the standard in symphony to the project was was standardizing on yaml But I didn't know that so at some point I I Had a couple of XML files there and then I was like, okay I need to figure out how to convert this to yaml And apparently it's it's pretty easy actually But there's a small catch and I wrote about that on my blog The problem is There is a repository dash class parameter in the XML But that that's not called repository dash class in the way yaml is repository underscore class because the dash doesn't work with yaml files Or something like that. It's a very small thing But it's really really annoying if you get stuck on that and this is a great example of you run into something You put it in your blog someone else will have that fixed a lot easier and simpler than you And actually someone I worked with at that point actually created a converter So it's converted of rostock.com and actually and so you just paste in an XML and it converts it automatically to yaml Or the other way around which is really useful So Russ went way beyond me. I just blocked about it. He just created the whole website for it So one of the problems with symphony both with components in the full stack is that you can do a lot of stuff in different ways As in there's there's three ways to do one thing and three ways to do another thing You can do configuration using annotations or yaml or xml or Plain PHP stuff like that and that's great, but it's also a problem Because if you if you Can do stuff in multiple ways I will do it in one way and Larry will do it in a different way And then we work on the same project and now we have one project where we have two different approaches for the same thing And that's a problem. So when you start a project Make sure that you all are on the same page you choose one way of doing things and do that And you don't run into the issue that I mentioned before with the xml and the ammo configuration It's very important for for the clarity of everyone for the readability for the maintainability as well because if I use annotations for routing and someone else uses a yaml file and in a year time another developer comes into that project and And he sees annotations in one place tries to use it in another place and it doesn't work because that one is using yaml files It's really really annoying and takes away too much time Even if you get back to the same project in the year's time, that's that's not good. So and and I mean this This works for PHP as well. This works for Drupal probably as well This works for any project that you do make sure that you that you choose one one way of doing things and standardize on that one Otherwise your code will be a mess So a couple of things that you can standardize on is the configuration. Are you using yaml? Are you using XML annotations plain PHP? Very important one is if you're gonna extend from the base controller or not Symphony offers a base controller that has some convenience Functions in there, which makes it a lot easier for instance to get to the dependency injection container however That also means that your code is less portable you're gonna you're gonna lean up on top of the symphony framework Whereas your controller can easily be registered as a service itself and be used as a service and then you can just inject the right Dependencies and That means that even if you don't use symphony you can still use the same controller in another class as long as you input the right dependencies And also naming of services and parameters and stuff like that There's a lot of different ways because it's just a string, right? It's just a string to identify your service It's just a string to identify your parameter and it's really annoying if if if you have three different ways of naming Your services and parameters to make sure you choose the right one way and stick with that a Good way that we're using right now in a project is that we prefix every service with the bundle that we're using So that we know from which bundle this service is so it's very easy to to if you if we find a problem It's very easy to find the right place where to fix that problem. Now. This is probably my favorite one Basically always use Composer always This is not just for symphony. This is this is if you want to use any PHP library these days It's just about using Composer because Composer makes it so easy to install new libraries Whether it's symphony or a Zen framework or anything else It it makes it so easy because it you don't have to worry about if the library that you're installing has any other Dependencies for other libraries because Composer will make will fix that Composer will know which other dependencies are there for that library and install those as well in the right versions When you work with Composer make sure that you commit both your Composer.json and Composer.log file into your repository If you just do the Composer.json and not the Composer.log file it might It will mean that another developer installing that project using Composer Might get a different version of a library than you have because the Composer.log file contains all of the information about which version You are using in that project So it's very very important to to also commit the Composer.log file If you run a Composer update because you want to install a new package Make sure that you specify the package in the update otherwise it will start updating all of your dependencies And that might mean that in some minor change in one of the libraries that you're using There's there's a backwards incompatibility and your project breaks and you have no idea which Library is causing this problem. You have to spend hours and hours and hours a Lot of time on trying to fix that problem Trust me. I've been there If you switch branches in your I don't know favorite version control package, I use git Make sure that you run Composer install again because it might be that the other branch has some other Version or maybe a new library or a different library than you're using right now It's very important to make sure that you have all those dependencies again So on every time you switch a branch make sure to run Composer install And in your Composer.log JSON make sure that you lock your packages to a version as much as possible and as specific as possible Because Well, as I mentioned before if there is in a in a minor update some libraries might Break records compatibility and that will that will break your whole product Or that might break your whole project and that's really annoying to the debug And now a slide that I added specifically for Drupalcom There is drush integration for Composer. I just looked it up this morning For those using drush. There is actually a plug-in for Composer so that you can do Drush Composer install or something like that That might might make it a lot easier to always use Composer I'm gonna grab some more water And again Composer is not just For symphony. Composer is something that's being used by a lot of PHP libraries these days So any time you work with any PHP library these days probably there is a Version for Composer available already So now that you're sort of ready for action. I'm gonna Mention a couple of small smaller tips and tricks that I learned If you're gonna work with forms with symphony full stack or even if you're not working with symphony full stack Try and use the form component The form component which for symphony 2 is really really good and really easy to use and it handles a lot of stuff It handles a C-Serve protection. It handles validation. It can plug into doctrine or another ORM or whatever you want for for data store Which makes it really really easy to use and you only need a couple of lines of code to create a new form It it makes it really really useful So even if you don't use symphony, it's the full stack. You can still use the forms component to do stuff like that Use bundles correctly I've seen projects that had one bundle the application bundle and everything was in there The whole idea with bundles if you work with symphony full stack is that you have one specific Functionality in a bundle and you can reuse that bundle in another project as well So make sure that you use bundles correctly and that you you basically split up every bit of your application into a separate bundle Sometimes you you bundle a couple of things together that belong together You might have different controllers handling different things, but as long as it all is still reusable That's the best way Also maximize external bundle usage There's a very good chance that whatever you want to do There is already a bundle out there that you can use that does exactly what you want to do Or even if it doesn't do exactly what you want to do, but just Slightly what you want to do you can extend on that bundle and just add your own specific functionality So that you don't have to reinvent the wheel So always check if there's a Bundle out there already. There's a couple of websites. You can just use packages org, which is from composer To search for bundles. There's also KMP bundles.com Which is really useful it gives some extra rating and metrics so that you can decide whether or not that bundle is good for you Always use the PSR0 naming standard. Yes Hmm or four. Yes. Okay. Sorry. Yes, or PSR4 naming standard either one of those Symphony is using them and the composer outer loader automatically recognizes classes that use this naming standard So that you can use the composer outer loader and actually I don't think that's in this slide But use the composer outer loader instead of your own outer loader for as much as possible You can configure a composer to recognize Non PSR0 classes as well So it's very easy to even for your old legacy classes To use composer outload instead of writing your own outer loader And using PSR0 or 4 will help you Um integrate stuff easier in a quicker way Yeah, I'm not gonna explain exactly what PSR0 or PSR4 is but it's in basically a naming standard that that tells you how to name your classes and how to Who how to convert that into a directory and file structure if you use twig I think Drupal uses twig right Drupal 8. Yes. If you use twig avoid using the raw filter Which outputs raw data? Well, I'm I hope I don't have to tell you why you shouldn't do that But it's for security. Let's let's just put it like that twig automatically Escapes your output which is really important if you use raw it doesn't so only use the raw if you really really need to if you trust the data It can be useful, especially if you put HTML markup stuff in into your database But really make sure that you really really trust the source of that markup When you start using symphony to the full stack the session directory is in the app directory And that's not the right place. Make sure you can you can easily change that in a configuration Make sure you change it to somewhere else Because if for some reason you clear your cache your session directory is gone Which can be really really annoying on production. It's okay if you're on development, but it's really annoying on production Similarly change the log directory by default. It's in the app directory and you don't want it there Your logs usually go to far log if you use Linux so configure symphony to use that directory as well very Important I've been bitten by this a couple of times add parameters of jammel to your git ignore file or whatever There's subversion or other version control that you use Variation is Parameters of jammel is environment specific so on my development machine. I use different values than on my production machine Actually, I don't want to commit my production passwords into my version control at all If by accident you commit it you update your server and for some reason your site doesn't work anymore It might be that your parameters to jammel is in your version control Because then it use using the wrong passwords and stuff breaks translate Symphony has very good support for using translations so you can easily use the translation component for Putting strings into your tweak templates and having it automatically be converted to whatever the right language is for the user That you're serving at that point So make sure to use that If possible and if needed So this is always the the nasty question. Should I use it from the start or should I not use it from the start? If you think you might go international It's it's very useful to start with translations because it's not a lot of extra effort that you put in But it's gonna save you a lot of time if after two years of work Your boss says okay, we're gonna start serving French as well as English Yeah going going through all of symphony trying to I've been there Trying having to convert all of the hard-coded strings into translated strings is really really annoying and Very important especially in the Drupal world if you don't do the full stack of symphony use components There's a lot of components in symphony that are really really useful for any project that you work on Actually, I'm on a project right now where we have a lot an old legacy code base and Refactoring or basically rewriting all of it at once would be way way too much work So we're trying to refactor pieces of the code to put in specific symphony components wherever it makes sense And that's really really a very easy way of Introducing symphony components into your project. Look at what Drupal is doing right now It's just taking a couple of components and and that makes Drupal at least for me Drupal a lot easier I know there's a there's a bit of Criticism from some Drupal users about the symphony stuff But it's really really a big step forward because now integration of a symphony code base and the Drupal code base for instance Is a lot easier and that makes it a very very very great for me at least because now I can use Drupal So that's it for me if there's any questions, let me know Don't be shy any questions. No questions Larry oh, yeah, that's If you can get there otherwise if I can hear it, I will repeat the question So you mentioned there's you know three or four ways of doing lots of different things in symphony like yes Annotations versus YAML versus XML versus whatever things like that Are there any conventions about what most people seem to be using for a lot of those or is it are there? Situations where one is going to work better than other or is it just purely subjective do what you feel like Well, obviously you can choose whatever you want the default symphony distribution has has some defaults if you if you take the standard distribution I think the service configuration is XML the main configuration is YAML and Routing is usually done with annotations But I mean Standardize on one way might be better because then it's consistent throughout your project But sometimes it makes sense to use a different Configuration I personally really really like annotations for my routing But I wouldn't put everything in annotations. I don't think even think you can put everything in annotations So just you know pick whatever makes sense Okay, so there's no like Aside from the defaults in full stack out of the box There's no everyone seems to be using YAML for this kind of thing type situation No, not really I although I've seen a lot of people move away from XML for the service configuration and move towards YAML because well most of the other standard configuration files are YAML So that sort of makes sense But it's yeah, I don't know it's it's really Depending on what you like Thanks Any other questions so you mentioned not to put everything in an application bundle. Yes What if you have coupling between bundles because you want to avoid that is there a way to have Multiple parts of an application that should be different bundles, but I talked to each other Yeah, so without using the applicant one bundle or yeah So if you if you really need coupling You could you could try using surfaces and Try to make the dependency as generic as possible so you can use the service configuration to to inject a Service from one bundle into the other bundle If you do it like that you can easily replace that bundle with a different bundle as long as it's it's the same interface That's okay So in that way if you have a hard dependency you have you still have the option of moving to something else Yeah Any other questions Might I add something to the discussion about XML and sure I actually think that XML is For some people for better for validation stuff So when you type at your ID will say okay. Well, this is valid XML and I think the pro for YAML is that you don't have to type that much That's just we are kind of lazy. So I think that's why people are also using YAML more and more Also, it's more flexible in in Moving your stuff around in the files and but I guess you know that too Yeah, yeah, exactly. Yeah, but that makes sense then to have one standard. Yes Any more questions? No more questions Right. I salute you If you need to get in touch, I'm at scoop on Twitter My blog is left on web.com even though I haven't blocked that much my company website is pay pay dot in critical to net and Then the joining link, please leave feedback so I can improve for the next time. Thank you very much