This article explores Drupal 8's Entity Validation API and its reliance on the Typed Data API for robust data validation, moving beyond the limitations of Drupal 7's form-based approach. We'll examine how this system enhances programmatic data handling and improves consistency across different data access methods.
Key Concepts:
FieldItemListInterface
implementations to manage data.The Need for a Better Approach:
Drupal 7 relied heavily on the Form API for validation, which proved cumbersome for programmatic entity validation. Re-implementing validation logic or simulating form submissions was inefficient and tightly coupled the data interaction with the form system. The advent of REST APIs and other programmatic interfaces in Drupal 8 necessitated a more flexible solution. Drupal 8 adopted the Symfony Validation component, building upon it to integrate with the Typed Data and plugin-based entity system. This ensures consistent validation across all interaction methods.
This article and its sequel will delve into the practical application and extension of the Drupal 8 Entity Validation API. We'll explore the underlying Typed Data API and provide code examples (available in a demo module within this git repository).
Understanding the Typed Data API:
The Typed Data API offers a consistent interface for data interaction. Its importance lies in defining and invoking validation on typed data objects. Key components include:
Example:
$definition = DataDefinition::create('string') ->addConstraint('Length', array('max' => 20)); $string_typed_data = \Drupal::typedDataManager()->create($definition, 'my string');
This creates a string data definition with a maximum length constraint and then uses the TypedDataManager
to create a StringData
plugin instance. The validate()
method on this instance triggers validation against defined constraints, returning a ConstraintViolationList
.
Typed Data and Content Entities:
Drupal 8 integrates entity properties and Field API fields. While some fields are base fields (essentially the old entity properties), others are configurable. Each field uses a FieldItemListInterface
implementation to manage data, typically containing FieldItem
plugins, each extending a DataType plugin and using a DataDefinitionInterface
implementation (often FieldItemDataDefinition
).
Adding Constraints:
Constraints are plugins containing validation details, error messages, and validator options. The validator class performs the actual validation.
Entity-Level Constraints: Added via annotations in the entity class. Example:
constraints = { "CommentName" = {} }
To modify entity constraints, use hook_entity_type_alter()
:
function demo_entity_type_alter(array &$entity_types) { $node = $entity_types['node']; $node->addConstraint('ConstraintPluginName', ['array', 'of', 'options']); }
Field-Level Constraints: Methods depend on whether the entity type is custom or core, and whether the field is base or configurable. For custom entity types, add constraints in baseFieldDefinitions()
. For existing entity types, use hook_entity_base_field_info_alter()
for base fields and hook_entity_bundle_field_info_alter()
for configurable fields. Example for a base field:
function demo_entity_base_field_info_alter(&$fields, EntityTypeInterface $entity_type) { if ($entity_type->id() === 'node') { $title = $fields['title']; $title->addPropertyConstraints('value', ['Length' => ['max' => 5]]); } }
Conclusion and Next Steps:
This article provides a foundational understanding of Drupal 8's Entity Validation and Typed Data APIs. The next part will delve into the validation process itself, handling violations, and creating custom constraints and validators.
(The provided FAQs section is omitted here due to length constraints, but it could be integrated as a separate section.)
The above is the detailed content of Drupal 8 Entity Validation and Typed Data Explained. For more information, please follow other related articles on the PHP Chinese website!