The Drupal 8 plugin system - part 3

Checkout part 1 and part 2 for understanding the concept of plugins. In this installment, we will be

  1. Implementing a new plugin from existing plugin types.
  2. 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.

The Drupal 8 plugin system - part 2

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:

  1. limited scope. Do one thing and do it right.
  2. 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.

The Drupal 8 plugin system - part 1

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:

  1. 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 in Drupal 8

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:

  1. How to actually differentiate between annotations and actual user comments?

2.

Pages