Drupal 7 introduced Entities as the main unit of data alongside an API to manipulate entities. This is changing the way we can develop Drupal-based applications. The aim of this presentation is to identify emerging patterns of usage to inform further refinement and development and support the spread of best practices for development.
How to Make Entities and Influence Drupal - Emerging Patterns from Drupal Contrib
1. Making Entities and Influencing Drupal
emerging patterns from contrib
Tuesday, February 8, 2011
2. Ronald Ashri
@ronald_istos
http://www.istos.it/blog
Tuesday, February 8, 2011
3. 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!
Tuesday, February 8, 2011
4. nodes are great
love drupal = love nodes
Tuesday, February 8, 2011
5. 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
Tuesday, February 8, 2011
6. secretly we all dream(ed) of turning everything into
nodes
...and almost did...
Tuesday, February 8, 2011
7. user profiles = drupal.org/project/content_profile
Tuesday, February 8, 2011
10. Entities in Drupal 7 are the nodes we really wanted
but didn’t know it yet
Tuesday, February 8, 2011
11. Entities is the stuff that makes up our site
nodes, users, taxonomy terms, comments
Tuesday, February 8, 2011
12. Entities were born out of the need to streamline
operation for:
“loadable thingies, that can be optionally fieldable”
(http://drupal.org/node/460320)
Tuesday, February 8, 2011
13. The relationships between Entities - the ways
entities can interact with each other - define our
Drupal application
nodes can have comments
users create nodes
taxonomy terms are attached to nodes
these relationships are implicit - perhaps they could be made explicit?
Tuesday, February 8, 2011
14. ok - so core does nodes, users, taxonomy and
comments
(still some way to go to a perfectly consistent implementation)
Tuesday, February 8, 2011
15. Drupal 7 allows you to create your own entities
your own loadable thingies with optional fields!
Tuesday, February 8, 2011
16. But how to use these loadable thingies?
Tuesday, February 8, 2011
17. 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
Tuesday, February 8, 2011
18. Drupal Commerce
Extending Drupal by adding domain specific
concepts
Tuesday, February 8, 2011
19. 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)
Tuesday, February 8, 2011
20. Drupal Commerce defines
Customer Profiles
Lines Items
Orders
Payment Transactions
Products
as entities
Tuesday, February 8, 2011
21. 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
Tuesday, February 8, 2011
22. 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
Tuesday, February 8, 2011
23. Organic Groups - Keep Basic Info and (possibly)
use Entities as a configuration controller
Tuesday, February 8, 2011
24. 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...
Tuesday, February 8, 2011
25. 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
Tuesday, February 8, 2011
26. An organic group entity is fieldable so you
could have...
Tuesday, February 8, 2011
27. an organic group entity that controls another
entity’s behavior as an organic group
(munch on that for a bit)
Tuesday, February 8, 2011
28. 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
Tuesday, February 8, 2011
29. 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
Tuesday, February 8, 2011
30. Media Module - Entifying existing data
Tuesday, February 8, 2011
31. base table of the media module is file_managed
file_managed is a “core” table
entity key = fid
file_managed modified in media.install
Tuesday, February 8, 2011
32. /**
* 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.
*/
Tuesday, February 8, 2011
33. 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
Tuesday, February 8, 2011
34. Entify external data - fold it into Drupal and now
you can add extra info via fields
Tuesday, February 8, 2011
35. 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
Tuesday, February 8, 2011
36. Cool Stuff to Look Out For:
Entity API: http://drupal.org/project/entity
This 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/relation
A relation denotes and describes the connection between two entities. A
relation is fieldable
Micro: http://drupal.org/project/micro
Micro is a small, lightweight, fieldable entity that attaches to other entities.
Tuesday, February 8, 2011
37. Thanks!
t: @ronald_istos
http://www.istos.it/category/blog-tags/drupal-
entities
Tuesday, February 8, 2011