| 1 |
Data API readme
|
| 2 |
***************
|
| 3 |
|
| 4 |
Do not try to install this module on a real site!
|
| 5 |
|
| 6 |
This is a module developed for demonstration purposes and not intended to be used on sites.
|
| 7 |
|
| 8 |
Intent:
|
| 9 |
|
| 10 |
Drupal's core object handling APIs are soundly designed but limited. Existing systems
|
| 11 |
for creating, updating, loading, and deleting objects like nodes, users, terms, etc. have
|
| 12 |
two main limitations:
|
| 13 |
|
| 14 |
* Lack of uniformity/consistency. Each object type has a distinct set of methods, accepting
|
| 15 |
different arguments and returning different data. This makes it difficult or impossible
|
| 16 |
to have uniform interactions with different object types.
|
| 17 |
|
| 18 |
* The data APIs are form-based, with limited support for programmatic operations. Specifically,
|
| 19 |
necessary schema information - data structures, default values, required fields, etc. = are
|
| 20 |
embedded in forms and not available to direct API operations.
|
| 21 |
|
| 22 |
The intent of Data API is to prototype a new uniform set of APIs for all Drupal object types.
|
| 23 |
The key assumption of the approach is that a data API should be schema-aware, with key schema
|
| 24 |
data residing in a single location and fully exploited.
|
| 25 |
|
| 26 |
If we know enough about our schema, we can programmatically save items; validate them, ensuring
|
| 27 |
all required fields are present; set appropriate default values; load data from foreign key source
|
| 28 |
tables; and so on. We can also programmatically generate basic input forms.
|
| 29 |
|
| 30 |
Data API defines schema information in a way parallel to the Forms API. That is, schema data are
|
| 31 |
embedded in structured arrays. Because all data types expose their schemas in the same format,
|
| 32 |
a single set of methods can be used for all types.
|
| 33 |
|
| 34 |
|