Drupal 7 Module Development

Creating New Fields
Again, there's no guarantee that we're even dealing with an SQL database. Aren't
you glad we're letting Drupal figure all of that out for us?
It is also possible to do more complex queries on fields, for instance, the
following one:
$query = new EntityFieldQuery();
$query
->entityCondition('entity_type', 'artwork')
->propertyOrderBy('created', 'DESC')
->fieldCondition('field_artist', 'value', 'Da Vinci', 'CONTAINS',
0)
->range(0, 5);
$result = $query->execute();
In this case, instead of using a simple "is exactly equal to" comparison, we are
asking for any entity whose field_artist field has the string "Da Vinci" in it
anywhere. That allows us to match both "Da Vinci" and "Leonardo Da Vinci". The
fifth parameter lets us restrict results to just those fields that have "Da Vinci" as
their first instance (remember, 0-based) if they are multi-value.
There are of course corresponding entityOrderBy(), propertyCondition(), and
fieldOrderBy() methods for building up more interesting field queries. See the
inline documentation in includes/entity.inc for the full range of options.
Summary
We have now completed a module that touches on the three most important parts of
the Field API. We've created a new field type to store data, corresponding widgets
to allow users to edit it, and formatters to control how that data is displayed when
the entity the field is attached to is viewed.
Although our use cases were reasonably simple, Drupal allows arbitrarily complex
Widgets and Formatters. Some Widgets can interact with the URL or third party
data sources to handle default values, or perhaps show a completely different set of
form fields under certain conditions. Formatters can use the theme system to display
data themselves or leverage JavaScript libraries to create interactive visualizations of
the data stored in a field. With swappable storage engines, advanced use cases can
even load data from another database or server entirely, including one that does not
involve SQL.
[ 210 ]