Also seeand .
Let’s add metadata about all entity properties, so any module can leverage this data and/or add more metadata around properties. The metadata should include a human readable label, optionally a description and a precise description of the data.
The entity API module introduces already hook_entity_property_info() for Drupal 7 (see here), but it sometimes requires additional data wrangling (getter, setter callbacks) and the use of wrapper objects. However, the goal for Drupal 8 should be to make this additional abstraction layer obsolete - by having properties matching their metadata in the first place, as well as an native and simple to use API that allows easy access to properties.
Why, for what and when is it useful?
- For improving entity-related DX! Based upon property information we can improve the entity API helpers, e.g. just use
$comment->get('node')->get('user')to get a comment's node's author.
- Generally, as foundation for all property based APIs (see ). It’s like having field info, without the restriction of having a field.
- As helper when transforming / exporting / importing data: Knowing your data and in particular relationships helps a lot when exporting/importing. Example: Restful services can add pointers as URIs (e.g. as seen here), UUIDs could be exported and “resolved” upon import, ...
- RDFa / microdata modules can define their mappings based upon the defined properties
- Basic default token replacements could be provided based upon property metadata.
Next, modules in contrib could do/do already:
- Search API already builds upon entity property metadata to know which properties can be indexed and how to get the values.
- Rules needs to know about properties for providing data-selection.
- Rules needs the metadata to know which property can be written too and what kind of data is suited.
- CTools’ context relationship API could re-use metadata about entity relationships.
- Probably many more...
Related, it's establishing a way to describe data in drupal (=metadata). That's needed in many places so we should settle on a single way to do so. E.g. a new Rules or a new Actions API for core would have to describe needed action paramters, or a block required contextual data.
But moreover, I think it’s crucial for the entity API to evolve based upon a property API. It potentially enables developments like:
- Auto-generating db-schema based upon property information (Yes, similar to fields.)
- Auto-generate forms based upon property information (like widgets)
- Auto-generate entity display components based upon property information (like formatters)
- Apply validations based upon metadata (validate it's a integer, or has to be a mail address). Think REST services.
WIP. Code is being working on in the "entity-property-*" branches of the sandbox at http://drupal.org/sandbox/fago/1497344