Drupal 7 Module Development

Creating New Fields
hook_field_extra_fields() lets us define, per entity type and per bundle,
what "extra fields" the Field system should be aware of. In our case, we loop
over all artwork types and declare that all of them have a title pseudo-field. That
pseudo-field is present both when displaying the edit form for artwork entities
(the first key) and when displaying them (the second key). In both cases the
definition is the same but we could easily make them different if we want.
There are only three keys to each definition. label and description should be
self-explanatory. The weight key defines what the default "weight" of the title
pseudo-field is in relation to other Fields (or pseudo-fields) on an entity. By setting
the weight to -5, we ensure that by default the title will be shown first.
There is no requirement that they stay there, however. Now that the Field system
knows about the title field, the user can easily drag-and-drop the title to appear in
between two different Fields, at the bottom of the page, or even not at all.
Finding entities and fields
Creating, editing, and deleting data is all well and good, and is a key part of any
content management system. However, there is also another important feature that
makes a CMS worthwhile–Searching.
In a very simple case, searching for data is easy. We have a database, we know
SQL, so let's rock and roll. However, Drupal doesn't restrict data to living in an
SQL database. In fact, with field storage engines a single entity could conceivably
live in a variety of different places. Consider the case of an artwork that has
pictures associated with it via a field that pulls images from Flickr, and additional
background information from a third party collection management system. Simply
resorting to SQL to find artworks matching some given criteria is not feasible, since
two of those three data stores is not an SQL database. Moreover, we may not
be able to predict the table structure of the one that is since Drupal creates its
database dynamically.
Fortunately, Drupal provides a unified query system for searching entities and fields.
Although it does not allow for searching across different data stores, it does provide
a data store agnostic way of searching for entities. (Searching across different data
stores is an incredibly complex problem, usually best solved by indexing all data
from various data stores into a single search index such as Apache Solr.)
[ 206 ]