We saw how to write a simple service container in Drupal earlier. We shall build a tagged service now. To illustrate a proper use case for tagged services, let's contrive a scenario where you add a pipeline custom filters to user text before rendering it on the page.
In the previous post, we saw how to add and manage modules and module dependencies in Drupal 8 using Composer.
Do you want to manage modules and dependencies the PHP way instead of the "Drupal" way? Don't know how to use composer with Drupal? Are you planning to ditch drush make approach and adopt a composer based workflow?
If you answered yes to any of the above questions, then you should read this post.
We got a basic understanding of what a Drupal service is previously. Let's put that into action by creating a simple service in Drupal 8. Take note that this service what we are about to create doesn't do anything useful yet, and is written with a pedagogical purpose in mind.
Drupal 8 has this concept of services, or reusable PHP objects. The distinguishing feature of services is that their initiation is configurable. In other words, we can configure what type of instance is created and when this instance is created in the code, mostly without changing the code at all.
Why is this a big deal?
Real world plugins have a lot more properties than the
label property mentioned in our breakfast plugin. To make our plugin more "real world", we introduce 2 properties, image and ingredients.
- Implementing a new plugin from existing plugin types.
- Implementing a new plugin type using the annotation based discovery mechanism.
As an exercise, let's first construct an imaginary scenario where the user of your Drupal site wants choose what they want for breakfast from a list of breakfast menu items.
We saw in part 1 how plugins help us in writing reusable functionality in Drupal 8. There are a lot of concepts which plugins share in common with services, like:
- limited scope. Do one thing and do it right.
- PHP classes which are swappable.
Which begs the question, how exactly are plugins different from services? If your interface expects implementations to yield the same behaviour, then go for services. Otherwise, you should write it as a plugin.
Plugins are swappable pieces of code in Drupal 8. To see how different they are from hooks, let's take an example where we want to create a new field type.
In Drupal 7, this involves:
Providing information about the field
hook_field_info- describes the field, adds metadata like label, default formatter and widget.
hook_field_schema- resides in the module's .install file. Specifies how the field data is stored in the database.
Annotations are PHP comments which hold metadata about your function or class. They do not directly affect program semantics as they are comment blocks. They are read and parsed at runtime by an annotation engine.
Annotations are already used in other PHP projects for various purposes. Symfony2 uses annotations for specifying routing rules. Doctrine uses them for adding ORM related metadata.Though handy in various situations, their utility is debated about a lot, like:
- How to actually differentiate between annotations and actual user comments?