18.10.2016 Views

Drupal 7 Module Development

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Working with Content<br />

Once again, our primary means of communicating with <strong>Drupal</strong> is through large<br />

structured arrays that define all the information we need. In this case, our $return<br />

array has a single entry, artwork. The string artwork, as the top-most key, will serve<br />

as the "machine name" of this entity, which is how it will be referred to in code. The<br />

label key specifies what name should be shown to the user. The base table, revision<br />

table, and object keys entries tell the entity system about how our artwork is going to<br />

be stored, and are used by the default controller:<br />

• The main table where artworks are stored is called artwork, which has a<br />

primary key field (the "id" field) of aid.<br />

• Revisions will be stored in a table called artwork_revision, and the revision's<br />

unique ID is called vid.<br />

• Since we're supporting multiple bundles, we also tell the system what field<br />

will indicate to which bundle a given artwork belongs. In this case, we use<br />

the type field.<br />

• The human-readable name of a given artwork is stored in the title field.<br />

The view modes key defines the different ways that our entity can be viewed. In this<br />

case we are defining a "full" version and a "teaser" version, just as nodes use, but<br />

we could define whatever view modes we wanted. Other modules are free to inject<br />

additional view modes via hook_entity_info_alter() as well. As usual, the key of<br />

the view modes array is the machine name of the view mode and the label property<br />

is the human-friendly name. The custom settings flag indicates whether or not the<br />

Field UI should allow field formatters to be configured separately for that view mode<br />

by default. It is easily changed via the UI.<br />

We also define a uri_callback function, namely artwork_uri(). That allows us<br />

to abstract out the definition of the path within <strong>Drupal</strong> where this artwork will be<br />

accessed. Instead of hard coding a path, such as artwork/$aid, we call a callback<br />

function to generate it for us. That is most important when listing entities of different<br />

types, as we can simply call a single function, entity_uri($type, $entity), and<br />

get back the correct information to pass to the url() or l() functions. Our simple<br />

callback looks like this:<br />

function artwork_uri($artwork) {<br />

return array(<br />

'path' => 'artwork/' . $artwork->aid,<br />

);<br />

}<br />

[ 158 ]

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!