How to Make Entities and Influence Drupal - Emerging Patterns from Drupal Contrib

Making Entities and Influencing Drupal

emerging patterns from contrib

Tuesday, February 8, 2011

Ronald Ashri

@ronald_istos

http://www.istos.it/blog




itinerary

• from nodes to entities

• brief explanation of what entities are

• Patterns of usage

• Drupal Commerce

• Organic Groups

• Media

• Cool stuff to watch out for

• Discussion / Questions

• Beer!


nodes are great

love drupal = love nodes


we love nodes because everything drupal does it does it around nodes -

so you get lots of stuff for free

oh, and node is a cool sounding geeky word that can mean anything you want it to


secretly we all dream(ed) of turning everything into nodes

...and almost did...


user profiles = drupal.org/project/content_profile


taxonomy = drupal.org/project/taxonomy_node


comments = drupal.org/project/comment_nodes


Entities in Drupal 7 are the nodes we really wanted but didn’t know it yet


Entities is the stuff that makes up our sitenodes, users, taxonomy terms, comments


Entities were born out of the need to streamline operation for:

“loadable thingies, that can be optionally fieldable” (http://drupal.org/node/460320)


http://drupal.org/node/460320

http://drupal.org/node/460320

The relationships between Entities - the ways entities can interact with each other - define our

Drupal application

nodes can have commentsusers create nodes

taxonomy terms are attached to nodes

these relationships are implicit - perhaps they could be made explicit?


ok - so core does nodes, users, taxonomy and comments

(still some way to go to a perfectly consistent implementation)


Drupal 7 allows you to create your own entities

your own loadable thingies with optional fields!


But how to use these loadable thingies?


Emerging Patterns of Usage

The are many possible ways to employ entities to solve various problems - this is a first step at trying to identify some specific patterns that we can reuse across application domains

We identify emerging patterns by looking at how entities are currently used in Drupal Contrib


Drupal Commerce

Extending Drupal by adding domain specific concepts


in order to add commerce capabilities we need to introduce a whole set of concepts (and their supporting data types)

in D6 this was done almost entirely “outside” of Drupal except Product which were nodes (which was a good fit but not ideal)


Drupal Commerce defines Customer Profiles Lines Items Orders Payment Transactions Products

as entities


Drupal Commerce defines as much as it needs in terms of fields attached to these entities - allows the user add extra fields where it makes sense


use entities to introduce new data types that can be user-extensible

provide minimum conf required

ps: you really, really, really need a good reason not to use entities when introducing new data (and data tables) to Drupal


Organic Groups - Keep Basic Info and (possibly) use Entities as a configuration controller


Organic Groups uses Entities because via the Entity API (drupal.org/project/entity) it gets CRUD, caching, etc for free

Less to worry about! But also...


Disconnect between the D6 way (node was a group) to:

Group Entity holds reference to actual Node that represents the group

separation of concerns opens up interesting possibilities and enables things that were not possible before like better internationalization support


An organic group entity is fieldable so you could have...


an organic group entity that controls another entity’s behavior as an organic group

(munch on that for a bit)


By adding fields to the Group entity that expose configuration options you allow the end user (site admin) to fine tune the behavior of specific group instances


use Entities to separate concerns -

using the Field API as a way to flexibly add access to configuration options

Site builder can decide how much config to make available to Site Admins


Media Module - Entifying existing data


base table of the media module is file_managed

file_managed is a “core” table

entity key = fid

file_managed modified in media.install


/** * DISCLAIMER: * Yes I am altering a core table. * No I am not on crack. * Basically, the problem we're facing is the media "type" which is not the * mime type, but is probably computed from it. * * The file table has no type field. As a result, we would have to either: * * 1). Create a media_files table to join them. This is nice and clean, * however it requires keeping the tables in sync, and it also means we have * to write our own SQL instead of using BaseEntityController, and that's * kinda scary. * * 2). Make the media type a "computed" field. Wherein, everytime we loaded * a piece of media, we would need to compute its type from the mime-type. * This is unacceptable from a performance standpoint and also requires us * override the Controller in ways we probably don't want to. * * I know it's a sin, but I think it is also excusable because: * * 1). This is hoping to be a core addition, so think of it as a core patch * that will eventually go in. * * 2). It is adding a new field, so it shouldn't cause any conflicts. If it * does that INSERT / SELECT code is badly written and should use complete * INSERTS or column names. */


What is going on is data is brought into the Entity way of doing things.

Something that could apply just as well to external data imported into your Drupal DB


Entify external data - fold it into Drupal and now you can add extra info via fields


Patterns

1. When you need to introduce new data types create entities that are configured as much as you require and can be extended by users

2. Use entities to separate concerns - enable expansion later on

3. When you need to provide multiple configuration options that can optionally be switched on and off use entities to allow the site builder to choose what configuration options are made available by adding or removing fields to a Controller entity

4. When you import external data and need to fold it into Drupal entify the data table and make it available to Field API and Entity functionality


Cool Stuff to Look Out For:Entity API: http://drupal.org/project/entityThis module extends the entity API of Drupal core in order to provide a unified way to deal with entities and their properties. Additionally, it provides an entity CRUD controller, which helps simplifying the creation of new entity types

Relation: http://drupal.org/project/relationA relation denotes and describes the connection between two entities. A relation is fieldable

Micro: http://drupal.org/project/microMicro is a small, lightweight, fieldable entity that attaches to other entities.


http://drupal.org/project/entity

http://drupal.org/project/entity

http://drupal.org/project/relation

http://drupal.org/project/relation

http://drupal.org/project/micro

http://drupal.org/project/micro

Thanks!

t: @ronald_istos

http://www.istos.it/category/blog-tags/drupal-entities






How to Make Entities and Influence Drupal - Emerging Patterns from Drupal Contrib

Technology

Transcript of How to Make Entities and Influence Drupal - Emerging Patterns from Drupal Contrib