Drupal 7 Module Development

Creating New Fields
3. We want to present a unified custom interface to users while editing that
data, especially if it is multi-value.
4. We want to display the data to the user in a custom format.
All of these are reasons why we may want to write our own field code.
In our case, we are dealing with artworks. Artworks have dimensions, either height
and width, or height, width, and depth. Although we certainly could just add three
numeric fields to our artwork bundles and call it a day, that is not very attractive
either for the content editor or for site viewers. It gets even uglier if we want to allow
multi-value fields; say if a given artwork is a collection of small statues or a series of
similar paintings.
We will therefore define a new type of field to store dimensions, either height and
width, or height, width, and depth. Although in our case we are talking about works
of art, the field itself would apply just as well to cars, buildings, animals, or any other
content that represents an object that takes up space. A good field type is generic
enough to fit many different situations.
How Field API works
As hinted above, there are several different complementary parts to defining a field:
• Field type: this is strictly speaking, just the content definition. It defines the
name of the field and what its inner data structure is, but not how to save it
or how to display it.
• Field: this is a particular configuration of a field type.
• Field instance: this is the combination of a particular field with a bundle or
subclass of an entity type
• Widget: this is a form element that exposes the field to a content editor. It
could use simple text fields or be something as complex as an interactive
Flash-based tool.
• Formatter: this is a piece of code that formats a field for display on screen.
Typically it just wraps Drupal's theme system to do so.
Note that nowhere in any of the parts mentioned do we define how or where the
data gets stored. That is handled by a field storage engine, which can be configured
separately per field. By default all fields use a common storage engine that saves
fields to Drupal's database. That's good enough for our needs, so we won't go into
field storage engines in depth.
[ 184 ]