Lingue

Drupal Entities - Part 1 - Moving beyond nodes

One of the biggest changes at the architecture level of Drupal 7 is the introduction of entities as an abstraction for content. In these series of blog posts I take a look at how Entities came to be, what are they exactly and how they can be used in modules. This first post goes looks at how entities landed in Drupal 7.

Drupal 7 introduces a lot of big changes at all levels. Amongst these, the use of entities as the primary abstraction for content represents one of the biggest shifts in the underlying architecture.

A telling sign of how deeply embedded entities are is that they don't even get a mention in the changelog for Drupal 7 - they are not a user-facing tool or abstraction in any way - purely an architectural tool to deal with content.

I originally intended to write one single post as a means to help me clear my understanding of entities and hopefully help others as well. However, one post is just not enough! So in what has now turned into a series of posts I am first going to do some historical digging to see how entities came about, then explain what entities exactly are and finally try to figure out how and where entities can be used in coding to build better modules.

So first let us try and figure out how things got to where they are now.

In the beginning there were nodes

Up to Drupal 6 nodes, as the main unit of content, could be considered Drupal's primary abstraction, with every other piece building or relating to nodes.

A lot has already been said about what a powerful tool that is. You add some functionality for nodes and suddenly any content on your site (as long as it is a node) gains that ability. From versioning, voting, translation, presentation fanciness as long as you wrote your extension to work with nodes you were sure it would work in all sorts of situations.

With Flexinode and later on the Content Construction Kit, nodes gained the ability to have fields added to them. This pretty much took Drupal to a whole new level of flexibility - so much so the ability to add fields to nodes became one of the main goals of Drupal 7.

Let us make everything a node!

At the same time, the Drupal 6 contributed module space provided proof of how people needed to add fields to more things than just nodes. You have modules that turn user profiles to nodes - for the explicit purpose of then being able to add fields to user profiles via CCK. Modules that turn comments into nodes, again just so you can add fields to them. Even modules that link taxonomy to nodes.

In fact, the "everything as a node" meme has a long history. A google search reveals that Robert Douglass as early as May 2006 suggested that everything in Drupal could be made a node and outlined the potential benefits of that.

This idea pops up in various other occasions and really I guess it can be considered the progenitor of entities.

Let's introduce a new concept

So, one the one hand you have a lot of people arguing about why it is great to have everything as a node so that CCK can be used to add fields to things. One the other hand, you have a huge effort under way to add CCK to the core of Drupal 7.

In a great demonstration of how the Drupal contrib space can act as a laboratory of what should happen in new versions of Drupal, and after some pretty amazing work by the Drupal 7 Field in Core developers the two ideas meet.

The "everything is a node" meme, takes shape in Drupal 7 as "everything is an entity" and a type of entity is a node. However, also users, taxonomy terms and comments are entities and entities can immediately plug-in to the Field API and have fields added to them.

However, the exact architectural solution to this didn't come about in one simple step. First things became fieldable (i.e. more like nodes). Then the need to streamline the functionality required to deal with things such as taxonomy terms, users, comments and nodes led to the introduction of entities as a means to group together all the code that was repeated in different places and standardize terminology.

If you go digging in the Drupal issue queue you find a great issue called "Standarized, pluggable entity loading (nodes, users, taxonomy, files, comments)" - there Frando makes the case for streamlining how to deal with "loadable thingies, that can optionally be fieldable".

Another interesting discussion is "Use the term entity instead of object, where the exact definition of Entities is discussed and this patch shows that even just a few months ago the code in Drupal was still not consistently using the right terminology (entities where referred to as objects) - but a some great efforts by Chx and yched fixed a lot of that.

Say hi to Entities

So now, just a couple of months away (fingers crossed!) from the release of Drupal 7, Entities are the new nodes.

If you want to introduce some new fancy way of dealing with things and take full advantage of the power of Drupal you don't need to write a module that turns X into a node, rather you create your own entity (take a look at the Awesome Relationships module for a great example).

This also means that one can now at least imagine a Drupal without nodes because the architectural tools to allow you to that are there. Nodes are just one type of entity. Of course, while you can imagine it actually getting that done at the code level is still not that simple since quite a few things are hardwired. But the first vital step has been taken.

With the historical synopsis out of the way in a couple of days we are going to look at what entities are exactly and then explore how you can make use of them in modules.

The second post is now online.

Third post is online describing how to code enitities in Drupal 7

Commenti

Nope these are not entities in that sense - entities should be thought of as drupal-specific terminology - just like nodes. While nodes mean different things in different contexts really in Drupal they just mean one thing. Same goes for entities - they just represent types of content that can optionally have fields added to it.

that's about right. it is nodes for everything - but turbo charged and given a different name because nodes already mean something.

I've only recently come to realize how the "entities" concept unifies so many of the changes in Drupal 7. As you say, it's not immediately apparent to the end user.

From my point of view, it's become more and more evident as the D7 release date approaches, and as bugs stop obscuring the entity-ness of various Drupal parts.

Inviato da Anonymous (non verificato) il

Entities in the way you described them are the next logic step in building Java or something similar into PHP. But when do recognize that the PHP basis is a dead end. You can't take care of all the shortcomings of the PHP basis. What you have done is a great approach. I never imagined that PHP can be developed so far. But to be honest its a vast depletion of time and energy. PHP is of preprocessor design and nobody can teach a frog how to fly. Hope the ideas of Drupal find their way into a new system based on a stable oop framework.

Inviato da jaxpax (non verificato) il

. . . describing a-not-so-easy-to-describe-topic. Nice with the historical perspective, making it all come together. Keep up the good work, Mr Ashri!

Inviato da Michael London (non verificato) il

I am at Drupal Con in Denver and this is my first experience with Drupal in any hard core way. I have been programming for a while so I am used to OOP but when Entities came around and then when I listened to the presentations...I admit I was a little confused. I gleaned from the sessions an understanding but your explanation above helped solidify my understanding of the concept!

Thanks

Aggiungi un commento

Plain text

  • Nessun tag HTML consentito.
  • Indirizzi web o e-mail vengono trasformati in link automaticamente
  • Linee e paragrafi vanno a capo automaticamente.
CAPTCHA
Questa domanda serve a verificare che il form non venga inviato da procedure automatizzate
By submitting this form, you accept the Mollom privacy policy.