Drupal 7 Module Development

Working with Content
• We may be accessing entities that are not stored in Drupal's local database,
such as a legacy data store.
• We may need to have internal variants, like node types, but nodes don't
support "sub-type types".
For simplicity we'll not do anything too exotic for now. Instead, we'll look at a
relatively simple use case and mirror node handling fairly closely.
The goal
For our example, we'll create a new entity called "artwork". This entity will represent
a work of art held by a museum and managed through Drupal. Like nodes, artworks
will have sub-types like "painting" and "sculpture". We will want to allow users to
create, edit, and delete artworks, as well as configure what fields are available on
each artwork type.
In practice most real museums would have their collection stored in a dedicated
collection management system and we would need to just provide a wrapper that
reads data from it in a Drupal-friendly way. For our purposes though we will
assume a very small museum that wants to use Drupal itself as a simple collection
management system, which implies full create, read, update, and delete capabilities.
Bundles
In earlier versions of Drupal only nodes had the ability to have sub-types. In Drupal
7, all entities have the ability to support sub-types. In Drupal parlance, these subtypes
are called "bundles".
A bundle is a sub-type of an entity that can be configured separately.
Node types are an example of a bundle. Not all entity types have bundles.
Users, for instance, do not have separate bundles.
For now, we'll hard-code two bundles, painting and sculpture. In a real use case we'd
be likely to also include an administration system to create and manage bundles.
The Schema API
We will need a place to store our artwork data, so we need to create some new
database tables. Rather than create them directly, though, we'll let Drupal do
that for us using a part of the database layer called the Schema API.
[ 152 ]