View
7.547
Download
0
Category
Tags:
Preview:
DESCRIPTION
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.
Citation preview
Making Entities and Influencing Drupal
emerging patterns from contrib
Tuesday, February 8, 2011
Ronald Ashri
@ronald_istos
http://www.istos.it/blog
Tuesday, February 8, 2011
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
nodes are great
love drupal = love nodes
Tuesday, February 8, 2011
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
secretly we all dream(ed) of turning everything into nodes
...and almost did...
Tuesday, February 8, 2011
user profiles = drupal.org/project/content_profile
Tuesday, February 8, 2011
taxonomy = drupal.org/project/taxonomy_node
Tuesday, February 8, 2011
comments = drupal.org/project/comment_nodes
Tuesday, February 8, 2011
Entities in Drupal 7 are the nodes we really wanted but didn’t know it yet
Tuesday, February 8, 2011
Entities is the stuff that makes up our sitenodes, users, taxonomy terms, comments
Tuesday, February 8, 2011
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
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?
Tuesday, February 8, 2011
ok - so core does nodes, users, taxonomy and comments
(still some way to go to a perfectly consistent implementation)
Tuesday, February 8, 2011
Drupal 7 allows you to create your own entities
your own loadable thingies with optional fields!
Tuesday, February 8, 2011
But how to use these loadable thingies?
Tuesday, February 8, 2011
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
Drupal Commerce
Extending Drupal by adding domain specific concepts
Tuesday, February 8, 2011
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
Drupal Commerce defines Customer Profiles Lines Items Orders Payment Transactions Products
as entities
Tuesday, February 8, 2011
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
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
Organic Groups - Keep Basic Info and (possibly) use Entities as a configuration controller
Tuesday, February 8, 2011
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
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
An organic group entity is fieldable so you could have...
Tuesday, February 8, 2011
an organic group entity that controls another entity’s behavior as an organic group
(munch on that for a bit)
Tuesday, February 8, 2011
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
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
Media Module - Entifying existing data
Tuesday, February 8, 2011
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
/** * 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
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
Entify external data - fold it into Drupal and now you can add extra info via fields
Tuesday, February 8, 2011
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
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.
Tuesday, February 8, 2011
Thanks!
t: @ronald_istos
http://www.istos.it/category/blog-tags/drupal-entities
Tuesday, February 8, 2011
Recommended