Drupal 7 Module Development

Working with Content
Drupal 7 introduces major changes to the way Drupal handles content. In earlier
versions, nearly all content was considered a "node". By making content a standard
object with a common API, any module could add data to and manipulate that object
to create complex data models and workflows.
That worked extremely well, with the exception that Drupal had several other types
of objects, such as users or comments, that were not really "content" per se but could
still have benefited from the same rich API. For Drupal 7, therefore, most of those
separate object types were merged into a single super-system known as "entities".
Nodes, users, comments, and several other types of data objects are now particular
instances of the generic Entity data object concept. That allows all types of data to
have the same, or at least very similar, API and workflow, avoiding duplicate code
and reducing the number of moving parts developers need to keep track of. Most
importantly, it allows us to attach Fields, discrete structured pieces of information,
to any type of entity rather than just to nodes.
In this chapter, we'll look at how to define new entity types. There are a lot of
moving parts, and while the entity system automates much of the process for us it
does not automate everything. Along the way we'll touch on several new pieces of
Drupal and reiterate what we've covered in previous chapters about page callbacks
and form handling.
Why create your own entities
It's generally not necessary to create a new entity type. Nodes are still extremely
flexible, and more often than not can handle whatever use case we need. However,
there are cases where it is necessary to create separate entities rather than separate
node types, like for instance:
• We may need entities that have entirely different permission handling or
workflow than nodes, such as products in an e-commerce system.