I’m a lazy developer. Probably one of the laziest I know. I try not to commit anything to memory that can be looked up with 2 seconds of typing and a click. If I know someone else knows the answer and they’re within earshot I’m definitely not going to sit around and try to figure it out myself. That’s not to say I won’t work hard or can’t learn, but it’s all about efficiency in the work place for me.
With that said, I love what the Drupal community is doing this time around with Drupal 8. “Proudly Invented Elsewhere” or PIE as I like to call it leverages a ton of code written not specifically for Drupal, but more generally to solve specific problems in web application development. Just like every Drupal developer reaches for a module to provide a solution, Drupal as a whole is bringing in functionality from a lot of established and battle-worn projects and incorporating them into Drupal’s core.
The biggest project being adopted is Symfony. Not all of it, but a good chunk of it will be incorporated into Drupal’s core. You can find a list of all components available in Symfony, but the list below shows you some of what’s been included so far.
Symfony
ClassLoader (PSR-0) and DependencyInjection
Namespacing and class naming standards and autoloading of classes when they’re needed. Following a standard PHP convention instead of a Drupalism also allows us to integrate third party code a lot more effectively and swap it out easily if need be.
Resources
- http://samhassell.com/dependency-injection-and-dependency-lookup/
- http://blog.merge.nl/2013/05/18/how-namespaces-spr-0-got-into-drupal-8
- PSR-0 path naming conventions
HttpFoundation and HttpKernel
These two classes help form the foundation that the WSCCI team is using to reinvent the request and response pattern of Drupal. WSCCI will abstract the structured data of your Drupal backend from the web based front end turning your Drupal site into more of a consumable service that could happen to have a website in front of it, but could also easily have an iOS or Android app as it’s interface.
Resources
YAML
YML files are replacing the info files previously found in themes and modules as a way to setup some basic information about both such as the name of the module, dependencies and version numbers. YML also comes into play in configuration management as a way to store core and module configuration settings in code as opposed to the database.
Resources
Routing
hook_menu no more. Well, not for defining callbacks at least. Instead you’ll define paths to callbacks in your module’s YML file and you’ll only need to invoke hook_menu if you’re actually adding menu items to a menu. Essentially though, you’re still defining a path that when executed runs some code.
Resources
EventDispatcher
Taking over eventually for the hook system currently in Drupal. The EventDispatcher allows your code to dispatch or subscribe to events. Dispatching an event will cause all listeners of that event to act on it. As far as I know for now though, you’ll be using a mishmash of both.
Serializer
Serializer essentially takes an array and morphs it into a different format. So build your array as you would in PHP and output that array as JSON or XML or any other format the Serializer component can output.
Validator
Like hook_validate except it’s not tied to forms. You can validate any data coming into your system. The validator component from Symfony provides a ton of out of the box validation constraints including things like valid country names and ISBNs in case you’re making some kind of book site.
Resources
Translation
Translation in core! This should be fairly similar to the combo of i18n and l10n modules. It also seems there’s more of a focus on entity translations than on content translations. Not sure how that’ll work with revisions, but sounds like a big step forward.
Doctrine Common
Doctrine (particularly the class annotation parsing) is used as the mechanism for discovery, definition and loading of plugins. Plugins provided by core so far being; Entities, Blocks, Field formatters and any Views plugins. With field formatters as an example, you would provide a class annotation to define the field info instead of using hook_field_info.
Resources
Assetic
CSS and JavaScript pre-processing and aggregation similar to RoR’s asset pipeline. This guy does a lot of fun stuff like minifying your CSS for you, optimizes jpg’s and png’s, and even supports SASS and LESS.
Resources
Aside from Symfony, a few other projects have been brought into the fold.
Composer
Manages external dependencies similar to Ruby’s gem bundler, but for PHP. You can use the default package repository called Packagist or you can host your own packages for private use using Satis.
Twig
Twig is the replacement for PHPTemplate as the default template system for Drupal 8. It was developed by Fabien Potencier who also happens to be the creator of Symfony so it should be pretty complementary.
Resources
- Twigify for converting D7 themes to D8
- Twig for template designers
- Twig for developers
- Twig coding standards
- Upgrading 7.x themes to 8.x
Guzzle
A more powerful replacement for drupal_http_request. It can handle persistent and parallel connections, comes with plugins for caching, loggins and different authentication methods and leverages Symfony’s EventDispatcher.
Resources
PHPUnit
Mostly doing away with the purpose built SimpleTest and adopting a more widely accepted testing framework. PhpUnit will provide a unit testing framework for standalone components of the Drupal framework. You’ll still need to use SimpleTest when a full or partial Drupal environment is needed, but this should help with all the third party components being introduced into core.
Resources
I’m sticking to the shallow end of Drupal 8 for now so if there’s any glaring omissions or mistakes let me know in the comments.
