Entities, in Drupal, are objects that are used for persistent storage of content and configuration information.
After releasing drupal 8, some of these are node (content), taxonomy term, user, comments, block, file, and the list continues. They all serve different purposes. The node entity type is intended specifically for the output of content where taxonomy term is meant for the grouping of content. Any instance of these entity types created with data input as defined by that entity type are individual entities.
Each entity is an instance of a particular "entity type". Some content entity types have sub-types, which are known as "bundles", while for other entity types, there is only a single bundle. For example, the Node content entity type, which is used for the main content pages in Drupal, has bundles that are known as "content types", while the User content type, which is used for user accounts, has only one bundle.
Entity types can further be divided into sub-groups with specific types of data for each while still maintaining overall the same functionality. For example, bundles for the node entity type are called content types and allow a user to define a specific set of fields for each. Drupal.org outlines the bundles for Drupal's core entities and even provides a diagram or map of the entities.
With the below diagram you can understand.
Web Developer
Bundles: Developer Type
1. Full Stack
2. Back-end
3. Front-end
Defining an entity type
Entity type are defined by module,using Drupal's Plugin API (see the Plugin API topic for more information about plugins in general). Here are the steps to follow to define a new entity type:
1. Choose a unique machine name, or ID, for your entity type.
2. Define an interface for your entity's get/set methods,
\Drupal\Core\Config\Entity\ConfigEntityInterface or \Drupal\Core\Entity\ContentEntityInterface.
3.Define a class for your entity, implementing your interface and extending
either \Drupal\Core\Config\Entity\ConfigEntityBase or \Drupal\Core\Entity\ContentEntityBase
4.In the annotation, the 'id' property gives the entity type ID, and the 'label' property gives the human-readable name of the entity type. If you are defining a content entity type that uses bundles, the 'bundle_label' property gives the human-readable name to use for a bundle of this entity type (for example, "Content type" for the Node entity).
5.The annotation will refer to several handler classes, which you will also need to define:
- list_builder: Define a class that extends \Drupal\Core\Config\Entity\ConfigEntityListBuilder (for configuration entities) or \Drupal\Core\Entity\EntityListBuilder (for content entities), to provide an administrative overview for your entities.
- add and edit forms, or default form: Define a class (or two) that extend(s) \Drupal\Core\Entity\EntityForm to provide add and edit forms for your entities. For content entities, base class \Drupal\Core\Entity\ContentEntityForm is a better starting point.
- delete form: Define a class that extends \Drupal\Core\Entity\EntityConfirmFormBase to provide a delete confirmation form for your entities.
- view_builder: For content entities and config entities that need to be viewed, define a class that implements \Drupal\Core\Entity\EntityViewBuilderInterface (usually extending \Drupal\Core\Entity\EntityViewBuilder), to display a single entity.
- translation: For translatable content entities (if the 'translatable' annotation property has value TRUE), define a class that extends \Drupal\content_translation\ContentTranslationHandler, to translate the content. Configuration translation is handled automatically by the Configuration Translation module, without the need of a handler class.
- access: If your configuration entity has complex permissions, you might need an access control handling, implementing \Drupal\Core\Entity\EntityAccessControlHandlerInterface, but most entities can just use the 'admin_permission' annotation property instead. Note that if you are creating your own access control handler, you should override the checkAccess() and checkCreateAccess() methods, not access().
- storage: A class implementing \Drupal\Core\Entity\EntityStorageInterface. If not specified, content entities will use \Drupal\Core\Entity\Sql\SqlContentEntityStorage, and config entities will use \Drupal\Core\Config\Entity\ConfigEntityStorage. You can extend one of these classes to provide custom behavior.
- views_data: A class implementing \Drupal\views\EntityViewsDataInterface to provide views data for the entity type. You can autogenerate most of the views data by extending \Drupal\views\EntityViewsData.
for more Details please read below.
Entity routes
Entity routes can be defined in *.routing.yml files, like any other route: see the Routing API topic for more information. Another option for entity routes is to use a route provider class, and reference it in the annotations on the entity class:
Loading, querying, and rendering entities
To load entities, use the entity storage manager, which is an object implementing \Drupal\Core\Entity\EntityStorageInterface that you can retrieve with:
$storage = \Drupal::entityTypeManager()
->getStorage('your_entity_type');
// Or if you have a $container variable:
$storage = $container
->get('entity_type.manager')
->getStorage('your_entity_type');
Here, 'your_entity_type' is the machine name of your entity type ('id' annotation property on the entity class), and note that you should use dependency injection to retrieve this object if possible. See the Services and Dependency Injection topic for more about how to properly retrieve services.
To query to find entities to load, use an entity query, which is a object implementing \Drupal\Core\Entity\Query\QueryInterface that you can retrieve with:
// Simple query:
$query = \Drupal::entityQuery('your_entity_type');
// Or, if you have a $container variable:
$storage = $container
->get('entity_type.manager')
->getStorage('your_entity_type');
$query = $storage
->getQuery();
If you need aggregation, there is an aggregate query available, which implements \Drupal\Core\Entity\Query\QueryAggregateInterface:
$query \Drupal::entityQueryAggregate('your_entity_type');
// Or:
$query = $storage->getAggregateQuery('your_entity_type');
In either case, you can then add conditions to your query, using methods like condition(), exists(), etc. on $query; add sorting, pager, and range if needed, and execute the query to return a list of entity IDs that match the query.
Here is an example, using the core File entity:
$fids = Drupal::entityQuery('file')
->condition('status', FILE_STATUS_PERMANENT, '<>')
->condition('changed', REQUEST_TIME - $age, '<')
->range(0, 100)
->execute();
$files = $storage
->loadMultiple($fids);
The normal way of viewing entities is by using a route, as described in the sections above. If for some reason you need to render an entity in code in a particular view mode, you can use an entity view builder, which is an object implementing \Drupal\Core\Entity\EntityViewBuilderInterface that you can retrieve with:
$view_builder = \Drupal::entityTypeManager()
->getViewBuilder('your_entity_type');
// Or if you have a $container variable:
$view_builder = $container
->get('entity_type.manager')
->getViewBuilder('your_entity_type');
Then, to build and render the entity:
// You can omit the language ID, by default the current content language will
// be used. If no translation is available for the current language, fallback
// rules will be used.
$build = $view_builder
->view($entity, 'view_mode_name', $language
->getId());
// $build is a render array.
$rendered = \Drupal::service('renderer')
->render($build);
Access checking on entities
Entity types define their access permission scheme in their annotation. Access permissions can be quite complex, so you should not assume any particular permission scheme. Instead, once you have an entity object loaded, you can check for permission for a particular operation (such as 'view') at the entity or field level by calling:
$entity
->access($operation);
$entity->nameOfField
->access($operation);
The interface related to access checking in entities and fields is \Drupal\Core\Access\AccessibleInterface.
The default entity access control handler invokes two hooks while checking access on a single entity: hook_entity_access() is invoked first, and then hook_ENTITY_TYPE_access() (where ENTITY_TYPE is the machine name of the entity type). If no module returns a TRUE or FALSE value from either of these hooks, then the entity's default access checking takes place. For create operations (creating a new entity), the hooks that are invoked are hook_entity_create_access() and hook_ENTITY_TYPE_create_access() instead.
No comments:
Post a Comment