With the release of Drupal 8, CMS moves closer to objects by integrating Symfony components. So, what are the main changes for Drupal users and what are these components used for?
Salah Meharga, CTO of SensioLabs, was kind enough to answer our questions and enlighten us on the subject.
SensioLabs: Hello Salah! First, what are the main changes when moving from Drupal 7 to Drupal 8 and what will this change for CMS users?
Salah Meharga: Before talking about Drupal 7 and 8, let’s look back at its history.
Originally, Drupal (versions 5 and 6) was a very precise procedural code. Version 7 and subsequent versions use a little more OOP (Object Oriented Programming), especially in API databases. Small steps were used to transition to OOP, maintaining procedural methods to avoid a big shift from what Drupal developers were used to.
The arrival of Symfony in Drupal 8 meant that CMS was more geared towards OOP and especially when Controllers and the dependency injection container were introduced.
Today, a Symfony developer will find it much easier to tackle a Drupal project because Drupal now uses Symfony components without any real abstraction layer.
What are the main benefits of Symfony in Drupal 8?
One of the main benefits is getting closer to market solutions. As an example, all modern frameworks use a routing component. Even with no defined standard, all frameworks have a common operating mode. Now, thanks to its Symfony component, Drupal has joined them.
The best benefit of Symfony in Drupal is the dependency injection container as this lets you reuse any code feature in any area, which is what the tool was previously lacking.
So, standardized development makes developing easier when you know both the object and Symfony. On the other hand, if you’ve used Drupal all your life and start using Drupal 8, you might find it hard to adapt. Symfony standardizes code, making it easier to grasp.
You said that Drupal 8 included the main Symfony components. What are these and how do they enhance Drupal 8 projects?
The main components are:
Console, DependencyInjection, EventDispatcher, HttpFoundation, HttpKernel, Routing, Serializer, Translation, Validator, Yaml…
Symfony components are like the framework, providing scalability and flexibility.
As I mentioned earlier, the dependency injection container allows any feature developed in Drupal to be reused anywhere in the code. Having a container with the names of all features means you can say to that container “I want to call this function object B rather than object A” and propagate this within the rest of the application. Now, you don’t need to search everywhere when replacing code etc.
Similarly, when you’re debugging, having an object with plenty of features makes it easier to ask that object to show you everything in the project. You can also ask to use existing functions again. Dependency injection makes it easier to access these features.
Have there been any major developments in event management?
In fact, Drupal previously used Hooks and these represented extension points just like an event does today. To record a hook, you had to create a function and say “here are my hooks”. Drupal then used these hooks and shared them with other modules. These hooks allowed other modules to perform additional operations. Symfony’s EventDispatcher means you don’t have to do this anymore.
By injecting dependencies you can use EventDispatcher anywhere. So, at any point in the code, you can ask the EventDispatcher to “dispatch” an event. You can create an extension point in just one line of code then all third-party modules can take this into account and enhance it.
This applies to modules as well as Drupal core, which has a list of pre-recorded events.
There’s a third-party component called Drupal Console, developed using the Symfony Console component and this is for debugging and/or listing events in the application. It’s a useful component for this task. Using the dependency injection container, you can ask the Event Dispacher to display all available events in the application. Drupal Console is essential for bridging the gap between Symfony and Drupal from a debugging point of view and for generating code (Controllers, modules …).
What’s the right approach to take when a Drupal developer wants to switch to Drupal 8 with Symfony?
You need to go through each stage and deal with the object before progressing to Symfony. Developers who’ve been using Drupal 7 won’t necessarily find this easy. Using CMS is clearly different than using OOP and can make it more complicated.
DependencyInjection, Routing, Controllers, Event Dispatcher etc. are modern concepts that you need to know about before you start developing in Drupal 8.
Before using Drupal 8, I think you really need to be fully trained in using Symfony. This can be specific Drupal 8 training or simply working through the Drupal and Symfony documentation very thoroughly.
Learn how to use Symfony components in Drupal with SensioLabs’ Symfony for Drupal 8 online course at university.sensiolabs.com/drupal
