Hello! In this post, I'm continuing my recap of DrupalCon Baltimore. In case you missed it, summaries of a few Tuesday events are in the previous post. The following are just a few of the sessions I was able to attend on Wednesday.
Wait, there are 35 Symfony Components? What Cool Stuff am I Missing?
Fellow Grand Rapidian Ryan Weaver, lead of the Symfony documentation team, presented this session describing the Symfony underpinnings of Drupal 8. Drupal 8 requires 26 of Symfony's components, each of which it uses to some extent. This presentation covered some of the components that Symfony has, and how you can use them in modules whether or not they are used by Drupal core.
- Debug: With a couple lines of code in settings.php, you can enable this component to produce much more attractive and easily-interpreted error messages.
- Finder: An easy and powerful way to search directories and retrieve a list of files. You can filter lots of ways, including by file name, wildcarded directory paths, sizes, etc.
- Console: A convenient way to write simple PHP command-line scripts. If needed, you can use the DrupalKernel object to bootstrap Drupal within your script
- FileSystem: Packages various file system management functions together (such as chmod, mkdir, mirror) in a consistent way. Can be combined with Finder to work on lots of files/directories at once.
- Process: Wraps system, exec, and so forth in a clean, safer interface.
- DotEnv: Rather than setting environment variables explicitly, you can have a flat file containing your environment variables. This can be used to make a development environment more convenient to configure.
- Expression-Language: A safe, side-effect-free language for expressing small conditional statements, which can be used to store business logic in the database if it changes often.
- PropertyInfo: Provides introspection information, such as variable types, by extracting information from comments.
- Workflow: Define states and transitions.
The Symfony site collects an exhaustive list of components with many more details.
All of these can be used on Drupal projects older than version 8, too. Just use Composer to require the components you want to use.
Twig: Tips and Tricks
This session was presented by Fabien Potencier, creator of Symfony and Twig. He began by outlining some of the architectural decisions underpinning the library, including its backward compatibility strategy (the same as the one currently employed by both Symfony and Drupal) and its focus on a small core and features provided through extensions.
The session was a laundry list of helpful features found in Twig, which are too numerous to list here. Check out the session recording for a full listing. Some of the items that particularly caught my eye follow.
Since Drupal arrays tend to have # characters prefixing some of their keys, you can't reference those values using standard Twig dot notation. In these cases, though, you can use bracket notation (as you would in PHP code) or you can call the attribute() function.
When you don't know if a variable is defined, the |default() filter is a safe way to handle this situation. You may also explicitly check, using expressions such as "is empty" and "defined".
When iterating with a for loop, you may use an "else" clause to handle situations when there are no items in a loop. You can also use an "if" clause to winnow the items in a collection you are looping over. The special variable called "loop" gives information about the current iteration of the loop you are in.
Fabien covered a variety of strategies for reusing templates. While there are many techniques, {% extends %} and include() are the most useful ones. Use {% extends %} to share layouts. Define an abstract template with {% block %} placehoders. Then, define other templates that extend this abstract template, filling in the placeholders appropriately. You can nest this inheritance.
Use include(), on the other hand, to reuse a small fragment of code in multiple places. You can also use it jsut to organize a large template into pieces, even if you don't intend to reuse those pieces.
Events: The Object Oriented Hook System
Nida Ismail Shah, from Acquia, presented this session on Symfony's alternative to Drupal's traditional hook system for delegating responsibility to modules.
In Drupal, hooks are the way for one module to invite other modules to take action. Hooks allow the application to be extensible and modular, since the code defining the hook doesn't need to know who will need to act when the hook is triggered. This in turn assists with maintainability, and improves the developer experience.
Hooks still exist in Drupal 8, but mostly as a legacy feature. New code should instead use the Symfony event dispatcher, which is an object-oriented approach to solving the same problem.
Most of this talk was too focused on code examples to cover here, so if you'd like more detail, check out the recording.
How I learned to Stop Wiring and Love Autowiring Containers
Beau Simensen of SensioLabs began this presentation by talking about the general concept of inversion of control, and the specific implementation of dependency injection. When using the inversion of control pattern, instead of creating an object yourself, some mechanism gives it to you without you knowing how exactly it was created. In dependency injection, the "container" is the object that handles the actual creation and management of the individual requested objects. This session discussed how containers can become aware of which objects are required in which contexts.
The presentation compared Laravel and Symfony methods of handling dependency injection. Laravel's Illuminate library uses autowiring, which leads to a better user interface, but at the expense of performance; Symfony is able to compile all of the wiring, leading to a much more performant outcome.
This led to a survey of extensions to Symfony's dependency injection capabilities, and a preview of the future: Symfony 3.3 will include auto-wiring and auto-configuring, so that all classes in Controller and Command directories are wired up without any configuration required at all. When Drupal upgrades to the Symfony 3 series (likely in Drupal 8.4), these capabilities will be available in Drupal as well.
Multilingual in Drupal 8: A soup to nuts guide featuring VisitTheUSA.com and Habitat.org
Representatives from Mediacurrent reviewed the current landscape of multilingual handling in Drupal 8, with case studies from two sites they recently constructed.
Drupal 8 provides four major modules related to translation, all of which should be enabled on a multilingual site: Configuration Translation, Content Translation, Interface Translation, and Language. This suite of modules produces a translation setup similar to enabling the contributed Entity Translation module in Drupal 7.
The required setup steps were detailed, and a couple of caveats were discussed. In particular, it bears mentioning that any views need to be specially configured with a filter, so that the current content language is displayed on the page.
During the Q&A time, I asked about the state of language fallbacks in Drupal 8, but there was not a clear answer. It seems that fallbacks to English are likely supported (which is the most common case), but I suspect scenarios without language fallbacks may still be a buggy affair, as they were in Drupal 7.
Need a fresh perspective on a tough project?
Let’s talk about how RDG can help.