Entity display system

A better way to define your entity displays

By: Jesus Larrubia (jlarrubia)

Group of elements making up its visual representation.

 

 

Display configuration

• WHAT is included
• HOW is represented

• 'content' property

Setting the display of an entity

Through Manage Display UI...

Deploying and exporting changes...

• Needs additional configuration management tool (Drupal 7 => Features).
• Export configuration to code.
• Save code changes (GIT)
• Deploy code (any deployment tool)

Problems

• Repetitive tasks - tedious process.
• Even editing directly exported code, turned out into repeating code (DRY).
• Not real FE/BE separation.
• Needs an additional module (Features) and problems derived from its use:
  • Performance
  • Increasing amount of modules
  • Incomprehensible chunks of code
  • ...

Our goal(s)

Avoid ALL these problems!

Requirements

• Speed up the process of managing display
• Based on the use of entities and view modes - blocks in our BEM methodology.
• Tool for (Drupal) developers
• Promote good development practices
• Easy deployment
• Real FE/BE separation - the FE layer must decide!

The solution...

sift Entity display module

1st things 1st... Defining WHAT

Text

entity_display.api.php

2nd things 2nd... defining HOW

entity_display.api.php

WHY this approach

• Separated concepts → WHAT and HOW
• Flexibility
• Remove problems, meet requirements

"Tedious"

"Incomprehensible chunks of code"

"This is speeder" ✓​

"I've seen this before" ✓

"Cool, I just need GIT and deploy code" ✓​

"I can define display by view mode or as I please!" ✓​

Let's improve it...

What about non field elements belonging to the display of an entity?

Standard solutions

• Extra fields - Manage display UI :(
• Computed fields - no BE/FE separation
• Blocks - Do they really belong to the entity?

• hook_entity_view, hook_preprocess_<entity_type> - I don't think this promote good practices...

Let's use the same approach then!

entity_display.api.php

How to define the display is unaltered

entity_display.api.php

Again...

• Transparency
• Render arrays (cached elements :)

"Promote good practices" ✓​

"I like to use Drupal standards" ✓

"I do know how to do this" ✓​

"I don't need any new module!" ✓

Module definition structure

• Separated folder
• One file per definition type
  • Entity display
  • Fields formatters
  • Render elements

"Promote good practices" ✓​

"Structured code" ✓​

"Incomprehensible chunks of code"

But... 

Bob (FE developer) could be happier

"The FE is still depending on the BE" ✖

Theme definition

• FE can choose WHAT elements are displayed and HOW.
• Overriding system.
• Definition structure following suggestions system.

Example: defining the display

node_full.display

node_full_resource.display

What does Bob think about this?

"This is real separation" ✓

"The FE power is finally mine!" ✓

entity_display.drush.inc​

Performance (Xhprof)

+ ~20%

Performance (II)

Cause: Drupal tries to load the display twice

Prepare field data prior to display.

field.attach.inc​

+ ~0-5%

"That's better" ✓

Solution: Skip unneeded display load (standard)

Performance (III)

entity_display.module

Questions?