 So welcome everyone to DrupalCon and to the first session of the symphony track. So then we just added the last few years at DrupalCon that I'm rather fond of. My name is Larry Garfield. You may know me online as Krell. If you want to make fun of me during the session on Twitter, that's where you do so. I highly recommend it. I am a senior architect with Palantir.net. We're a digital agency based in Chicago in the United States. We work mostly but not exclusively with Drupal. We also do some symphony work, some Sylex work. We're an end-to-end company. So design, content strategy, development, custom modules, site architecture, pretty much everything except hosting we do. For Drupal8, I was also the web services initiative lead, which means I'm the one you can blame for the fact that we have a symphony track at DrupalCon. Also the Drupal representative to the PHP framework and probability group. Who's heard of FIG? A decent number of people. So for those who don't have their hands up, FIG is basically the United Nations of PHP with all the positive and negative implications that has. I'm the advisor to Drupalization and I do implement PSRA-huggable interface. So I do most Drupal people. So let's talk about symphony. That's kind of why we're here. Specifically symphony 2. Symphony 2 is a Tier 1 PHP framework. By Tier 1, I mean it's one of the big boys. It's probably one of the, I think at the latest stats, it's one of the top three frameworks in PHP in terms of its usage and adoption. It's also the basis for a lot of other projects, including the number one, which is Laravel. It's a loosely coupled framework. Not a fully decoupled system, but the way symphony is built. It's a series of loosely coupled components that are then assembled into an application framework. But you can assemble those components together into different application frameworks, which is how you get things like symphony full stack, Sylex, Laravel, and Drupal 8. Now loose coupling is why symphony 2 was really one of the kick starters of the Revolution PHP and the PHP Renaissance of the last five or so years in the PHP 5.3 era. Symphony was one of the early drivers of that. And in fact was the incubator for Composer. Was it worked with Composer? Correct answer. Thank you. So Composer grew out of the symphony community. They saw a need and unlike the rest of the PHP world at the time, decided let's not make this specific to us. And that helped change the face of PHP. So who are you? I don't know. Who are you? He's Andrew. Okay. I'm Larry. Good to meet you. I'm going to assume that you know Drupal 7. You're a Drupal developer. You've worked with Drupal 7 before. You may or may not know some of Drupal 8. You may have worked, dabbled a little. You may have worked in issue queues. I'm not sure. But you want to move down stack. I mean you want to get less UI in the way. You want to do more framework driven work, more straight application work, less automation, more code. You want to be building pure applications, not just CMS type stuff. Who falls into generally this category as described? All right. I'm in the right room. Quick show of hands. Who has worked with Drupal 8 to some degree so far? Excellent. Who has no Drupal 8 experience whatsoever? Who here is actually a symphony person or a Drupal person who's just here to troll me? Knew it. So the first question I often hear from Drupal developers looking at Drupal 8 is, so I'm going to have to learn symphony in order to understand Drupal 8. I hear this all the time and the answer is a resounding no. If you're here to learn about Drupal 8 specifically, there are plenty of other sessions to go to instead of this one. This session is about symphony. Because as I said, symphony is a decoupled system, a loosely coupled system. So the way symphony is built, you have the symphony component libraries, which are mostly decoupled, mostly standalone. Some of them have a few dependencies, but for the most part these are standalone components that you can use. And then there's various partnered libraries like the twig templating system, the doctrine, monologue, various other projects that are not part of symphony but get used by symphony. And then those get tied together by something called the symphony framework bundle. Bundles we'll talk about are the symphony equivalents of modules essentially. And this kind of glues everything together. It's roughly the equivalent of system module, but for symphony, it's not quite that ugly though. Then symphonies add-ons called bundles that you can attach and build whatever kind of application you want out of those. Some of the bigger ones are the CMF components, the content management framework. Drupal is actually using some of those too. And that together builds the symphony full stack framework. And that's what we're going to be talking about today. Contrast Drupal 8 uses some of the symphony components, about a third of them actually, it doesn't use even the majority. Many of the same partnered libraries, but then it also has its own component libraries we've built, its own Drupal core libraries that are just part of Drupal itself, then its extensions, both the ones that are bundled with core and add-ons, you can build distributions with that. They are siblings. Drupal 8, symphony, Sylex, Laravel are all siblings or cousins, but they are not the same system. They are different to work with. And that's what we're talking about here. So who wants to learn how to develop for symphony? Good. Step one, go read the documentation. It's excellent. Really, the symphony documentation team does a great job. Their documentation is really solid, especially for the components as well. So I'm not going to cover the things that are already covered there. Instead, what I want to cover is coming from a Drupal perspective, here are the gotchas. Here are the things that are going to trip you up, that are going to confuse you, that you should be aware of when you go to read the documentation, when you go to try and build a project, the things that you need to think about and be aware are different than we're used to in Drupal. So, first of all, who is the system for? Well, Drupal's primary audience is content strategists. It's not developers. It's people doing content modeling. It's people managing the site long-term. It's people creating content through the site and curating content. That's Drupal's primary audience. Its focus in what it tries to enable is letting people build stuff on the web without having to write code. That is essentially Drupal's mission statement. Build cool stuff on the web without writing code. Symphony, by contrast, is aimed at professional PHP developers. It is aimed at people who are writing code for a living and like it that way. It's ideally suited for bespoke applications. That's custom, all right, what do you want? Let's just build it. Let's go with it. Rather than take one application and customize it, it's a little bit for each client. Its mission statement is essentially make writing code on the web easier. Not avoid it, but make it easier to do. Take care of the boring parts so you can focus on the interesting parts of your application. That distinction carries through pretty much the entire system. That's the biggest shift coming from a Drupal world. Both systems are highly configurable, but the biggest difference in Drupal, we have this big complex user interface, lots of forms, lots of configuration options, lots of user-friendly dialogues, yet Symphony, not even a little. The whole point of Symphony is your writing code, editing things on disk. There is configuration, there are files on disk. Usually they're YAML files, but they can be other things. And there is no UI for them at all. That configuration is not read at runtime every time. Instead, it's compiled into a generated PHP class by the development process and incorporated into the dependency injection container as parameters and properties. This is how Symphony's configuration works. You edit files on disk and check them in again. Extensions for Symphony, as we mentioned, are called bundles, essentially the same concept as modules, but even things like enabling one, you do by hacking code. You edit code for everything, even just turning on extensions. Those bundles can have their own configuration, and it's going to be files. In fact, the standard way to configure a bundle is look at its documentation, copy and paste these lines into your configuration file, into your YAML file, and edit to suit your taste. That is the way you configure bundles in Symphony. There are some bundles that provide some level of administrative interface, the most popular of which is the Sonata admin bundle. As I said, there are others. This is from their online demo of their dashboard. It looks kind of fancy. This is all a bundle. None of this is core Symphony. In this case, we've got open comments and orders, list of customers. Note this message here. You can customize this dashboard by editing this YAML file. The current dashboard presents recent items, blah, blah, blah, blah. If you want to make any changes to this admin whatsoever, you're editing a file. You're editing a template. You're editing a configuration file. Everything you do is going to be crack open your code editor. In this case, we're showing some really just basic roll-ups of information here, so customers, number of pages, number of orders, these are just data objects. You've got the post list for post a specific type of content on their particular demo app. There's no generic concept of post in Symphony. There's an edit screen for cars. Again, part of their demo app that looks a little bit fancy, but this is all hard-coded in this bundle. There is no configuration here. There is no fields. This is hand-crafted interface. It's got a user interface, or a user admin interface, but it doesn't actually provide users. Symphony itself does not provide users out of the box. This is an add-on as well. In Drupal, we're used to modules like organic groups that let you take existing content objects and through the UI enhance them and turn them into these clusters and allow users to be associated with them and so forth. We use the modules like panels, which give you an incredible amount of power through the UI to define complex layout rules and pull out content from various parts of the system based on various business rules, complex configured rule engines, essentially. For layout, no. There is no such thing in Symphony. It is not the way the system is designed to work. It's just culturally against the way Symphony works to do something like that. You want to change your layout? Go into the template file. That's what it's there for. I mentioned even things like users are not baked into Symphony. You can roll your own users if you want. It's not that hard. We use this bundle called FOSS user bundle which provides something vaguely on the same lines as Drupal's user support, ish. Gives you users, gives you a couple of admin screens that you can wire up. But this is an add-on. Actually, the Symphony project I worked on last didn't use it because we didn't need users logging in, so we didn't have it. We did something completely different for authentication. Incidentally, this FOSS here is for Friends of Symphony. The closest equivalent Symphony has to contrib. Symphony does not have a single canonical universe of add-ons, the way Drupal.org is for Drupal. So there are a number of useful bundles that are under the Friends of Symphony banner. It's just a GitHub group, really, of kind of high-level, well-maintained bundles. But for the most part, they're randomly on packages or via Google. So when you're developing for Symphony, most of your DevTools are going to be from the command line. In Drupal, we have a lot of tools in the UI. You switch your modes in the UI and so forth. In Symphony, they're all command-line tools. With one exception, which is the DevToolbar they have in Symphony, which is actually really, really, really cool. A lot of things are done with code scaffolding. Symphony itself ships with a command-line console tool and a lot of commands built on that, many of which are code generation. So you say, I want to spin up a new entity, I want to spin up a new controller, new various other things. And it's actually really useful. You're going to use that a lot developing for Symphony and for Drupal 8.2. Who's heard of Drupal console? Those of you who don't have your hands up, Google it. I think it's just drupalconsole.com. It's an excellent tool. It's built on the same Symphony console component and inspired by the Symphony console. The lead developers for it are actually people who have done both Symphony and Drupal work. And it has a lot of scaffolding tools as well, which you're going to want in Drupal 8. We also have this dev prod, development versus production toggle concept in Symphony. In Drupal, we have these caches. You can turn on and off. And CSS segregation, you can turn on and off. And these settings, you know, error reporting, you can turn on and off and do all of these things independently of each other. And that means there really is no development mode and production mode. And we tried to get that into Drupal 8.2.2.2.2 and got pushed back because, oh, too coarse-grained. They're wrong. Not that I have a strong opinion or anything. In Symphony, there's a development mode and a production mode. And never the screen shall meet. You have separate configuration files for them. And that's what it comes down to. You don't have a ability to finagle little bits here and there as easily as you do in Drupal. Which for the kind of stuff you're doing with Symphony is just fine. That also means that when you're doing... when you're switching to production mode, you need to force rebuild all of your caches. They do not self-clear. Like in Drupal, if you have an empty cache for your container or for generated content or for CSS and JavaScript aggregation, Drupal will just rebuild the stuff on the fly as it needs to when you're good. In Symphony, the production mode, you have to rebuild it manually. It never happens automatically. Which makes it a lot faster because it has to do less work and think about fewer things, but you have to think about them instead. Architecturally, there's a lot of changes here. A lot of differences. First one, we're all those Drupal 7 developers out there. We're used to functions, right? Not a single one. Symphony is a completely object-oriented system. There are no functions anywhere in the code base to bust my knowledge. Michelle, am I right on that? Okay, Michelle says I'm right. There are static methods in a couple of places, but not many. So it is a completely O system. If you're used to writing functions, get over it if you're working with Symphony. Instead, most of your logic is going to be in services. Meaningful logic belongs in services. What is a service? A service is a stateless business logic object. It contains no data. It does not change once it's instantiated. It is wired into your dependency injection container, and that is your application. The vast majority of your business logic in Symphony belongs in stateless services. Everything else is glue-code to connect those together. This is very different than Drupal 7, where we just had piles of functions lying around, and some of them collected data over time with statics, and some of them didn't, and there are, oh my god, globals. None of that in Symphony. Things are stateless services. You want to architect that way, and incidentally, if you're developing for Drupal 8, you do the same thing. This applies equally well to both systems. The configuration in Symphony is very un-opinionated compared to what we're used to in Drupal. So I mentioned that there's configuration files, usually YAML, usually being the operative phrase there. Symphony actually supports PHP, XML, YAML, or annotations for nearly all configuration. It is possible to configure a Symphony application using any of these exclusively. Most sites will use a mix of YAML and annotations in practice, but that's not a hard rule. Please, please, please pick exactly one for your own project. Save yourself a lot of pain and anguish. That said, you may run into third-party bundles that you install, where this one decided to use XML for its configuration, and this one encourages annotations, and this one uses PHP just to be different. Most of them, I think, at this point use YAML and annotations, but you have to be familiar with all of them because different bundles may make different decisions. For your own work, I do recommend YAML for as much as possible. If for no other reason, then that's what Drupal is using. Drupal is far less forgiving in this regard, it's far more opinionated, and our configuration is all YAML, period. The Drupal way, in this case, is actually much stricter than the symphony way. That said, you're not going to get away from annotations. In practice, I don't think anyone does a completely annotation-free symphony these days, so you're going to have to work with those one way or another. But really, what it comes down to, in other cases, we're doing some kind of metaprogramming. In Drupal, that metaprogramming is done via the UI. In symphony, it's being done via YAML. By metaprogramming, I mean configuration that is pretty much code on its own, that then drives the real code. That's essentially metaprogramming. You're doing the same kind of thing in both cases, but in Drupal, it's all via the interface in symphony, you're hand-editing files. How about theming? The word theming doesn't actually exist as much in symphony because you don't really have swappable themes the way you do in Drupal. There are some bundles that have things called themes, but I've never worked with them. I don't quite see their purpose compared to the way Drupal uses them. So templating, really, would be a better phrase here, which brings up probably the biggest difference for front-end folks between Drupal, anyversion and symphony, is that you only get one template. Period. That's it. One. In Drupal, we have this, you know, a spacked Russian doll model where you render this part with this template and this part with this template and bring those together into this larger piece and render that with the template and bring that into a larger piece. That's just not how symphony works at all. It has a template, only one template. How does that work? It works through Twig's inheritance system. You don't have to use Twig with symphony, but pretty much everyone does when they're doing HTML output. So how does this inheritance system work? Well, let's look at the default out-of-the-box demo index HTML template, index HTML to big in symphony. It's not quite fitting here. So we've got our markup and we've got some placeholders for it, but what's this block thing here? And style sheets are coming after the content. How does that work? That makes no sense at all. I'm going to recognize this at this point. The important thing here is this extends keyword. Extends in Twig is pretty much the same as extends in object-oriented code. Base HTML Twig looks like this. Ah, there's our template. There's our actual file. And we call out these blocks called title, style sheet. This title has some default values, style sheet does not, body, JavaScript. The block here has absolutely nothing to do with blocks as Drupal defines them, not even the slightest. Blocks in this case are really closer to methods that back in this template, we are extending this template and then overriding the body block with this template fragment and overriding the style sheet block with this template fragment and not overriding the title. So we just get the default title in the parent template. This is how you do more complex advanced theming for different parts of the page in Symphony. This capability does exist in Drupal because it's Twig. It's a standard feature of Twig. We're just not using it all that much in Drupal 8. That said, I encourage you to do so. Not for this. Not to try and turn the entire page into one template, Drupal will not like that. However, you can have custom versions of templates. Say, have a node.html.twig for theming nodes and then extend that for nodes of type article, nodes of type page, nodes of type event. And use extends that way. Core is not really doing that. You are welcome to do so in contrib themes. I highly encourage it. But we do not go as far with it and cannot go as far with it as Symphony does, where you've got this one template per request. Let's talk about extending Symphony now. Now, Drupal developers, what is the first thing you learn about Drupal, about developing for Drupal? What's that? Clear cash. What's the second thing you learn? Don't hack core. That's right. If you're developing for Drupal, every time you hack core, God kills a kitten. Don't do that. Please think of the kittens. In Symphony, you're exactly supposed to do that. What? How do you enable a new bundle in Symphony? Well, you have this app kernel.php class that is provided by the system out of the box. And, oh, you want to add more bundles to your system? You edit this file and just add a new, whatever the bundle's class name is. You can have bundles that only run in certain environments. So only the web profiler and this distribution bundle, they have to have been dev and test modes instead of in prod mode. You want to do it differently? You want to structure this differently? Go ahead. You want a network sending a base class here? You want to override something else from the base class? Go right ahead. You're encouraged to do so. This is weird. So let's look at the Symphony project, how it's actually put together. Again, this is the Symphony Standard Edition. So we've got this basic project. This is the default install. I have done no customization at all to this. We have an app directory, bin, source, vendor, and web. And then our composer files put everything together. So bin is a couple of, it's like where the command line tool lives. There's a few other things there. It's fairly uninteresting. Web, however, contains not all that much. App.php, app.dev.php, these are your front controllers, you have the length of index.php for Drupal. And these are actually hard-coded differently. This one is hard-coded to prod mode. This one is hard-coded to dev mode. So you want to look at your site in dev mode? You go to your site.com, dev.php, slash, blah, blah, blah, blah, blah, blah. Oh, you don't like it this way? You want to use an environment variable or something instead to switch it? Go ahead and hack these files. Really, I know people who do. One of my colleagues at Palantir does. And there's nothing else here in PHP code. Drupal puts all of its PHP code and everything else in the doc root. Simply puts almost nothing in the doc root. This is really the only PHP file it's going to have. You should probably strip out the config.php after you set it up initially. It's really just a setup wizard. If a bundle ships with assets, like CSS or JavaScript, those will get sim-linked in here or generated files produced and dumped in here by one of your compile commands. Fender. Everyone who raised their hand for Composer should know this. This is where your Composer downloaded packages go. Do not check this into your repository ever. Drupal is doing this wrong, yes. And do not edit anything in this directory ever. But note, symphony itself is in here. Symphony itself is a dependency of your project. The only thing that is outside of here is boilerplate that is provided for you. Please hack. Completely different than the way you approach a Drupal site. The app directory is where your configuration lives. So these are those configuration files I was talking about. By default, yaml. Config.yaml is your shared configuration. And then we have a separate config file for every environment. So we can have different configuration for dev and test and prod. And this is where you put it. To override that default configuration. You also have your routing information is here in the yaml file. Separate routing for development. So you can have paths that only exist in dev mode. I'm not sure if you can do it at the services, to be perfectly honest. But these are all your files. Edit them as needed. And those will all get compiled into a PHP class that lives in cache. Now Drupal 8 is doing some of this too where it's actually generating PHP classes for twig. So all twig files get compiled into PHP, put on disk, and then that's what runs. The dependency injection container and all of your configuration gets compiled together into one gigantic multi-thousand line class which is actually pretty fast as long as it's not larger than your APC cache size. Yes, I tested this. Then resources. Resources are what Symphony calls assets. So templates, CSS files, JavaScript files, all that kind of stuff are resources. And your top-level global templates and CSS and so forth will go here. All of this is yours to edit including the app kernel we saw before. You may not need to, but all of this is yours to edit. And then the source directory. This is your application. This is where your code for this application goes. This is the stuff that does get checked into your Git repository. You can put any, almost any structure you want here to be perfectly honest, the convention is to have a single bundle called app bundle which contains the code specific to this particular application. That's not a requirement. That's just the recommended convention. This is in contrast to Drupal where we'll have a custom module which is really no different than any other module. It's just where we dump stuff for a particular site but you're encouraged to break stuff up into separate modules and no one module is special over another. In Symphony, your site specific stuff is just all in one big blob bundle here and that's actually going to be a lot of code whereas in Drupal we try to keep it to a minimum. The discovery for that, all it looks for is a class which it doesn't even look for. We specify this class in the app kernel. We just name it and it loads that class and the auto loader finds it and poof. We're done. And then it builds some stuff off of that namespace automatically. So that is your discovery. You have a class with that name and you reference it from your own code. If you're building a reusable bundle of some kind as part of a project which just like in Drupal I'd say if you can do that, great, do so. You put that in a separate repository and pull that in via Composer. So one project may have three, four, five Composer repositories that go with it. Your actual project repository and then a couple of add-on bundles you've built you may or may not be releasing, maybe you're sharing to other internal projects, whatever. Those are then considered third party dependencies. The vast majority of the code in your project will live in the vendor directory as a third party dependency. And that's a good thing. So given that, as you're going through your project, as you're going through your development process in Drupal it usually looks like this. Push buttons. Write some custom code. Clear the cache. Push some more buttons. Clear the cache again. Clear the cache another time just for good measure. Then check it in and you're good. And, you know, depending on your version you may have a feature export you have to do in Drupal 7 or a CMI export in Drupal 8, but same idea. In Symphony, you write code while in Dev Mode. And for the most part it just kind of works immediately. There are few things you do need to manually clear in Dev Mode which is annoying, but for the most part Dev Mode rebuilds its caches every single request. That's why it's Dev Mode, that's why it's much slower than Prod Mode. Once you have everything working the way you want you clear your production cache one time, which is actually several commands because there's a couple of different caches you have to rebuild and each of them have a separate command just to keep life interesting. Actually it's for decoupling reasons, but still it's kind of annoying. And then you really, really want to build a deployable snapshot. What's that? Well, do you really want to check out new code to your production server directly and then run Composer Update and wait for that to run and then run Cache Clear and wait for that to get rebuilt which takes a couple of seconds. And in all that time a request comes in it has no idea what to do because our code is all convoluted and out of sync. You really should do this for Drupal 2 but it's much more important in Symphony's case. So once you generate your production version you clear your production cache you can take a tarball snapshot of that entire project and deploy that. Take that snapshot and push everything including vendor into a Git repository and then just check out in production that one snapshot. A couple of ways of doing this that's a whole other session. But look for production artifacts is the way you want to use Symphony. You can do that with Drupal 2 in Drupal 8 I do recommend it but it's just not something we're used to doing in the Drupal world. Drupal 8 and Symphony are using the same underlying kernel. So who has seen this picture before at some point or some variant of it? About half the room? Okay. So the basic core pipeline of most Symphony based applications which includes Symphony, Drupal 8, Sylex, a whole bunch of others is we have this HTTP kernel class. So a request comes into the system a request event fires Drupal people think hook request alter essentially. Then there's a controller event hook request post routing alter basically. Then a controller aka page callback fires and does whatever that request is going to do and it can return a response or not a response. If it returns not a response a view event fires and then any number of view listeners is able to take a look at that controller result and say do I know how to turn this into a response object? Yes. Okay, I'll do it. We're done. Or no, I'll let the next one handle it. Either way, we end up with a response object there's a response event hook response alter that gets sent back to the browser then there's a terminated event to do something and clean up and we're done. Both Symphony 2 and Drupal 8 use this pipeline they use the exact same code for it. However, they use it very differently. In Drupal you always are using the view event. You may not be writing a code for it yourself in fact you usually will not be but the view event is always used on 98% of requests the view event is going to fire and do whatever it's going to do. Symphony you can but the conventions in Symphony actually discourage leveraging that. I think this is kind of weird personally it's done for performance reasons but I think it's architecturally a weaker way of doing it because it doesn't separate concerns as well. I'm a fan of the action domain responder model and that's what Drupal is using here. So let's look at an example of Symphony controller. This is again straight out of the demo bundle that comes with the Symphony full stack. So first thing to note in Drupal our controllers are methods named whatever you feel like. In Symphony there's some black magic involved. I don't fully comprehend when this is a case but in almost all cases the controller method ends in action. It's roughly intended for grouping methods in a class but that's just the way Symphony is going to work. Then we're returning the results of calling this render with a template name and this array of parameters. Ignore the actual information here for the time being that's not relevant. Essentially what we're doing here is like calling the theme function in Drupal 7 or Drupal render really and returning the results of that. In Symphony this is encouraged. This is the recommended way of doing things. In Drupal you return a render array. You do not call render yourself. It's just not a thing. Don't do it. In Symphony you do it. Maybe, maybe not. You can in fact also return an array from here and use another annotation to say by the way the template you should use for this controller is this other template and then that array will get passed by the view listener. Again, I like that approach myself but it does have a performance overhead. That's why it's discouraged. Also note in this case we're using an annotation for the route to could be an YAML, could be an annotation your project could go either way. There's long arguments about which way is better or more sustainable. Please just be consistent. Speaking of paths and speaking of routing though in Drupal 8 if you want to register a route you're going to generally use a routing.yaml file in a module and then by turning on the module all of those routes will automatically get entered in the system. If it's a dynamic route of some kind it's based on user configuration there's an event that fires like hook menu alter type thing where you can create additional routes that way. All of those paths in those routes are rooted at your site route always. There's no magic nesting happening. All of those paths are very fixed patterns. Node slash ID, user slash ID, that's how all of the routes work and then we layer aliases on top of them to make it look pretty for users in search engines. In symphony well you can have a routing file which could be YAML or XML or PHP or as we saw on the last slide there could be annotations on a controller. There could be any of these. I'm not actually sure if there is a dynamic mechanism. From what I've seen actually there's a couple depending on which module you're building off of and then it does use path nesting. Those routing files are not registered automatically. Just loading a bundle doesn't register its routes. You have to go to the routing file up in app and explicitly say by the way include this other bundles routing.yaml file and root it at this path prefix. If you have routes that are being provided by the FOS user bundle you can say all of those routes I want to start with a slash user path and then everything in the FOS user bundles routing file are off of that path. Or on another side to say I want them all rooted at slash admin or slash bob or slash go away this is mine whatever. And then instead of aliasing the convention is to use slugs. Slugs I have no idea where this comes from to be perfectly honest but slugs are short string identifiers for a data object. I actually need to go a little bit faster here for a data object. The rough equivalent would be if you've done Drupal sites where you have a text field a hidden text field that is put a path fragment here and then you use path auto to say the path aliases always content slash field that is essentially what you do. Personally I like the Drupal way better but this is how symphony works. Storing data in Drupal we have a lot of it. In Drupal 8 we've got entities we've got the new state API we have our configuration API for information you want to be deployable we have the key value API in symphony you get doctrine just doctrine. Or something else if you feel like dropping it in but doctrine is what most people use is a completely standalone PHP project from symphony it has its own release schedule its own staff a lot of people who are part of both symphony and doctrine but it is a standalone ORM object relational mapper and it really only supports simple objects we'll see this I'm going to repeat this a lot it does not have the capabilities that entity API has pretty much you get a one-to-one mapping from database fields to properties on the object and that's as much as you get in terms of your data capability and if you want to do something with Mongo there's a separate add-on for that called the object document mapper doctrine ODM or yeah doctrine ODM that in theory works for any document system but in practice Mongo is the only one that works so let's compare these in Drupal our entities are configuration driven you have what Drupal calls bundles like node types and these are configurations user configurations of rich fields all fields that you configure are inherently multi-value even if you only have a single value in them you can figure them to pretend to be single value at a code level they are all multi-value period and these are rich data types we're talking about so it's not just string and int but email field telephone number street address entity reference that's the level that Drupal works at doctrine is much more primitive everything is a custom class all your entity types are custom classes you define and they only have simple properties on them things that can map pretty straight forward to an SQL field none of them are multi-value you can declare a field as being an array in which case it gets stored as a serialized blob in the database exactly these are really simple data types only it's much more rudimentary and if you want to have something that's a multi-value searchable field the way to do that is make another entity for that and you reference it multiple times it's coming from Drupal this is actually really painful for me to work with because it is so primitive compared to what I was used to in terms of how expressive it was some gotchas there it's just coming from Drupal it's very primitive it does a lot it does handle a lot of stuff for you you basically never touch an SQL schema yourself but if you're coming from Drupal entities it is going to feel very very primitive the SQL the default SQL version and the MongoDB version have very different APIs I don't just mean SQL and Mongo are different they are but the capabilities the way you model the data is different there are just modeling capabilities that are only there in the ODM version the Mongo version and a lot of the event names are different the command lines tools for clearing the cache are different a lot of things are needlessly different between the SQL and Mongo versions that is something that really annoyed me the first time I used Mongo with it there are events with doctrine pre-save same basic idea but they are different event listeners than the symphony event listeners because doctrine is a separate project and has its own event system it makes sense that it's that way it's still annoying you still need to be aware of it I actually know some people who will write bridge code to mutate doctrine events into symphony events so that they don't have to deal with that difference file handling on the web is a huge pain period actually does pretty good in this regard compared to a lot of systems doctrines is fairly even more primitive okay that said there are still similarities this is actually part of the point this is one of the reasons why Drupal 8 was refactor as heavily as it was because there are similarities between symphony and other modern systems and Drupal 8 now biggest one services we saw the slide before your meaningful logic belongs in services they are stateless this is where your business logic goes loosely coupled or fully decoupled classes that you instantiate through your service through the dependency injection container this is true of symphony this is true of Drupal 8 this is true of Laravel this is true of Zen framework most modern PHP frameworks work this way this is why symphony moved to this why Drupal moved to this model event listeners Drupal has event listeners in it mostly around the kernel those should be glue code in both symphony and in Drupal your event listeners should just be glue code that hands off to a service incidentally your hooks should be the same way don't put lots and lots of business logic into hooks in Drupal put that in a service and then the hook just bridges out to it the underlying kernel it is the same kernel it is the exact same code we are staying in sync, we are just pulling in symphony as a vendor for Drupal so if there is something you would do in a request event to tweak the request somehow it is going to be the exact same code both ways hooks and listeners are essentially the same idea listeners are a bit more heavyweight a bit more elegant more testable hooks are a bit lighter weight we have a lot more hooks in Drupal then symphony has listeners in part because of tagged services this is a tool of the symphony dependency injection container that both symphony and Drupal 8 use where instead of having an event which is actually fairly heavy you can set up services to relate to each other all services with this tag on it that I have configured get used this way, get thrown into this other service that can iterate through them so that dichotomy exists with symphony and in Drupal 8 and of course twig give or take the template inheritance otherwise it is the same twig almost all the same syntax almost all the same capabilities almost all the same tools the same auto escaping logic the same general awesomeness go talk to Morton, go to one of his sessions later today or tomorrow not quite sure when a session is if you want to know more about why twig is awesome as I said you can answer yourself for your own templates in Drupal 8 which I do encourage in symphony you'll be using it for everything and with that said go forth and make something musical thank you you've got about 9-10 minutes left so if you have any questions there's a microphone right over there or I can repeat stuff if you can't get through the microphone I answered everyone's questions completely that's amazing I just wanted to sort of sort out one mystery that you talked about whether that you know the action post fix on the action names so that basically is part of so there are actually two ways how to define a controller or bring it into the system and one is basically by a naming convention and that's the one that you showed and there you have to have your actions have to be post fixed with the word action and the second one is defining controllers as services and there you basically can just use whatever method names you want so that's the difference there okay so for those who don't know Lucas Smith of symphony Drupal using symphony is also his fault so you can blame him thank you for that other questions? other clarifications? I think we've got someone coming up here Michelle do you want to correct me on anything? hi Larry the container the dependency injection container the PHP file that you mentioned about the deployment version like a tar file is there any best practice around multi node in a production environment like how to either keep them centralized in one location or in a different node and if something goes wrong how to bring the like a regenerate them in production if we have to how to deal with all the compile code environment that's something that's actually very different between Drupal and symphony in symphony the answer is you're going to generate it on your dev box once with a command line tool and then take that whole snapshot and push that to all of your web heads at once and it will never change once it's on those web heads unless you specifically redeploy to your web heads in Drupal this is actually something we just fixed like in the last two weeks where we didn't know how to do that what we actually switched to I believe I could be wrong on this is the compiled container and compiled twig now actually stored in an index in the database rather than on disk so that's another big difference between the way symphony and Drupal are using the generated code so I haven't actually looked at all the details on the Drupal side there and they may change again probably no but in symphony's case you do not regenerate that code on your web head you regenerate it beforehand and then push that generated code to all of your web heads at once and then it's never going to change on there same with your CSS and javascript if you're doing any aggregation or compression with those you're doing all of that offline and then pushing that out to your production servers you mentioned Drupal 8 ships with symphony so what happens when you find a bug in symphony because it ships with core do you file a patch for core for symphony what happens when that patch gets committed to symphony does that warrant a new Drupal core release so how does that work excellent question the so Drupal 8 does have the symphony components we're using checked in to our repository this is mainly because we screwed up our Composier usage and haven't fixed it yet hopefully we'll fix that soon if we've that said it's still untouchable code if you find a bug in Drupal that turns out to be in a symphony component that gets fixed upstream in symphony what I would recommend file a bug with Drupal first file a bug with symphony preferably with pull requests if you can then file a bug in Drupal saying by the way here's this bug the link to the symphony bug for it so we can track it that way and then we'll close our bug when symphony fixes theirs and we will be keeping up to date on symphony bug fixes throughout Drupal's release so I'm not sure the exact schedule for it but expect when we have our bug fix releases monthly we'll probably be updating to the latest symphony patch versions at that point and I believe the plan is to also go with symphony minors when Drupal minors ship so Drupal 8.1 will update to whatever the latest symphony release is as of around then so we'll get all those bug fixes as well Hi Larry, imagine this scenario Drupal 8 has been fully released in a stable version you're not here in DrupalCon and a client come and wants to make a project that is quite complicated it's not a WordPress project which technology will go for you are completely free to choose a technology which one you will choose between Drupal 8 and symphony it's really going to depend on the project the deciding factor for me is Drupal does an awful lot for you there are certain things that if done with Drupal will take you a tenth as long as with symphony but then they're done in a Drupal way does doing it the Drupal way actually fit your use case if yes, great use Drupal, that's why it's there if on the other hand you're going to find yourself fighting against Drupal the whole way and the assumptions Drupal makes around its UI the assumptions it makes around the way content is structured if those assumptions are wrong in your case then write your own assumptions with symphony here's a good example we had a project about a year and a half ago I think where a client came to us and they wanted to build what they said was a CMS but the data they were storing, they had a couple million records and the data they were storing really did not fit well into a node structure nodes are a very specific structure with fields that are rich fields those are multi-value and you don't have nested fields inside fields you can kind of sort of do stuff like that with field collections or multi-field and other modules like that but it gets unwieldy very very fast so the data didn't really fit it and then they wanted a user interface that really didn't fit Drupal's view page and edit page model they specifically wanted Drupal and so we ended up doing it in Drupal in hindsight that project should have been done in symphony because it would have let us just skip trying to fight Drupal's interface assumptions we ended up building some custom fields to store data fragments as XML strings in a text field that we could then deserialize on load and it's what we had to do to put it into Drupal but that's a place where the more free form nature of doctrine would actually have been a better fit so it really what it comes down to, Drupal makes more assumptions if those assumptions are correct for you great, use Drupal, save yourself loads of time if those assumptions are wrong and you're going to spend your time fighting Drupal then skip the assumptions just build it yourself with symphony thank you and enjoy the rest of the conference for both this session and any others you go to please do fill out evaluations online it's very helpful for speakers it's helpful for the conference we're Drupal so we don't use joined in whatever but do go to the Drupalcon website and fill out evaluations for sessions there for all of the sessions you go to thank you