DrupalCon London 2011: UNIFIED ENTITY API
Problem:
Unified Entity API as Part of the Configuration Management Initiative
The divergent APIs and representations for different core entities means that there can be no standard way to export, import, or configure them.
In addition, this makes Drupal core harder to develop and maintain, and make the module builder DX worse too.
An Entity Property API for Drupal 8
Having the entity API unifying CRUD for Drupal 8 is already a great step forward. It seems obvious that it should handle full CRUD, but for it to be really useful we need to care more about the entity properties, fields and their differences.
While fields feature APIs for validation, access information, widgets, display formatters or translatability, we have nothing like that for regular entity properties. However, for modules to be able to work with entities in general, we need some of those features for regular entity properties too. Consider the use-case "RESTful web services", or any module that wants to generically use or update data from entities, like the Search API or Rules already do.
Proposed solution:
Unified Entity API as Part of the Configuration Management Initiative
As a sub-effort of the Configuration management initiative, we need to standardize the core Entity API.
catch and I discussed this possibility in Chicago. This conversation will be an update on progress and plans going forward.
An Entity Property API for Drupal 8
The entity API module achieves already something similar in Drupal 7. It comes with an Entity property information system, which kind of wraps Drupal's divergent data structures behind unified data wrappers.
However for Drupal 8 we want to avoid the need for unnecessary wrappers. So we need to come up with an API that fulfills developer's needs without anything extra. So should be everything a field then?
I'd like to present and debate a slightly different approach: The entity property API, which cares about an unified and easy way for accessing and updating property values, validation, access information as well as other property metadata.
With such an entity property API in place, fields could very much build upon this generally useful API and complement it wherever necessary. Related, we might want to look into streamlining field storage and entity storage, and provide a storage system that can handle translatable properties out of the box.
Unified Entity API as Part of the Configuration Management Initiative
The divergent APIs and representations for different core entities means that there can be no standard way to export, import, or configure them.
In addition, this makes Drupal core harder to develop and maintain, and make the module builder DX worse too.
An Entity Property API for Drupal 8
Having the entity API unifying CRUD for Drupal 8 is already a great step forward. It seems obvious that it should handle full CRUD, but for it to be really useful we need to care more about the entity properties, fields and their differences.
While fields feature APIs for validation, access information, widgets, display formatters or translatability, we have nothing like that for regular entity properties. However, for modules to be able to work with entities in general, we need some of those features for regular entity properties too. Consider the use-case "RESTful web services", or any module that wants to generically use or update data from entities, like the Search API or Rules already do.
Proposed solution:
Unified Entity API as Part of the Configuration Management Initiative
As a sub-effort of the Configuration management initiative, we need to standardize the core Entity API.
catch and I discussed this possibility in Chicago. This conversation will be an update on progress and plans going forward.
An Entity Property API for Drupal 8
The entity API module achieves already something similar in Drupal 7. It comes with an Entity property information system, which kind of wraps Drupal's divergent data structures behind unified data wrappers.
However for Drupal 8 we want to avoid the need for unnecessary wrappers. So we need to come up with an API that fulfills developer's needs without anything extra. So should be everything a field then?
I'd like to present and debate a slightly different approach: The entity property API, which cares about an unified and easy way for accessing and updating property values, validation, access information as well as other property metadata.
With such an entity property API in place, fields could very much build upon this generally useful API and complement it wherever necessary. Related, we might want to look into streamlining field storage and entity storage, and provide a storage system that can handle translatable properties out of the box.