The last main group of settings found on the entity type plugin annotations are the handlers. Handlers are the objects used by the entity API to manage various tasks related to entities. The Node entity type is a good example to look at because it defines quite a lot of them, giving us an opportunity to learn:
* handlers = { * "storage" = "Drupal\node\NodeStorage", * "storage_schema" = "Drupal\node\NodeStorageSchema", * "view_builder" = "Drupal\node\NodeViewBuilder", * "access" = "Drupal\node\NodeAccessControlHandler", * "views_data" = "Drupal\node\NodeViewsData", * "form" = { * "default" = "Drupal\node\NodeForm", * "delete" = "Drupal\node\Form\NodeDeleteForm", * "edit" = "Drupal\node\NodeForm", * "delete-multiple-confirm" = "Drupal\node\Form\DeleteMultiple" * }, * "route_provider" = { * "html" = "Drupal\node\Entity\NodeRouteProvider", * }, * "list_builder" = "Drupal\node\NodeListBuilder", * "translation" = "Drupal\node\NodeTranslationHandler" * },
As we can immediately notice, these are all simple references to classes. So, when in doubt, it's always a good idea to go and see what they do and how they work. But let's briefly talk about all of them and see what their main responsibility is.
- The storage handler is one of the most important. It does all that has to do with CRUD operations and interacting with the underlying storage system. It is always an implementation of EntityStorageInterface and sometimes a parent of the ContentEntityStorageBase or ConfigEntityStorage classes. If the entity type does not declare one, it will default to SqlContentEntityStorage (since we are using a SQL database most of the time) or ConfigEntityStorage for configuration entities.
- The storage_schema handler is not something you will deal with too much. Its purpose is to handle the schema preparations for the storage handler. It will default to the SqlContentEntityStorageSchema if one is not provided and it will take care of the database tables needed for the entity type definition.
- The view_builder handler is an EntityViewBuilderInterface implementation responsible for creating a render array out of an entity with the purpose of preparing it for display. If one is not specified, it defaults to EntityViewBuilder.
- The access handler is an EntityAccessControlHandlerInterface implementation responsible for checking the access for any of the CRUD operations on a given entity of the respective type. If one is not provided, the default EntityAccessControlHandler is used; it also triggers the access hooks modules can implement to have a say in the access rules of a given entity. We will talk a lot more about access in a dedicated chapter later on.
- The views_data handler is an EntityViewsDataInterface implementation responsible for exposing the respective entity type to the Views API. This is used so that Views is able to properly understand the entity and fields. By default, it uses the generic EntityViewsData if one is not provided.
- The form handlers are EntityFormInterface implementations used for various types of entity manipulations such as create, edit and delete. The referenced classes are forms that are used for managing the entities.
- The route_provider handlers are EntityRouteProviderInterface implementations responsible for dynamically providing routes necessary for the respective entity type. The Node entity type defines one for HTML pages, but others can be defined for other kinds of HTTP formats as well.
- The list_builder handler is an EntityListBuilderInterface implementation responsible for building a listing of entities of the respective type. This listing is typically used on the administration screen for managing the entities. This is an important one to have since, without it, the admin listing won't work. The default implementation is EntityListBuilder.
- The translation handler is a ContentTranslationHandlerInterface implementation responsible for exposing the entities of this type to the translation API.