Drupal 7 Module Development

Working with Content
Summary
This has been quite a chapter. Not only have we learned how to create our own
entities in Drupal, we have expanded our knowledge of many of Drupal's
key systems.
• We've seen how to define new entities and encapsulate their loading and
saving routines into a controller class.
• We've seen how to integrate our entity with the Field API, providing
site administrators with enormous flexibility and power to build custom
data models.
• We've learned how to define new tables in Drupal's database in a
database-agnostic fashion.
• We've learned about database transactions, a simple way to ensure that
a complex database operation succeeds completely or fails completely
to avoid data corruption.
• We've learned about how to avoid stale data issues when using
master/slave replication.
• We've seen how to display confirmation forms to users to ensure they didn't
click a button by accident.
• We've learned how to have dynamically named forms which are built using
the same process.
• We've seen how to leverage Drupal's autoloading capability for classes
to help keep code size down.
As noted at the start of the chapter, in many cases a custom entity will not need the
full life cycle of creation, editing, and deletion. Some may not even interact with
Drupal's local database at all, relying on a load() method that calls out to a ReST
service or SOAP server. We may need to define a complex set of permission controls
for our custom entity, or in some cases there may not even be a way for users to view
an entity directly.
By looking at a complete example, however, we have got a feel for most of the pieces
we could implement if we needed to. Since our artwork example closely parallels the
node entity type, although in a simplified form, it helps to provide a context for how
the all-important node system works in Drupal.
[ 182 ]