The History and Future of Drupal Theming

by Carl Wiedemann (c4rl)Wednesday 2013-09-25 • 14:15

Hi!

c4rlCarl Wiedemann

Where have we been?

Where are we going?

Discussion and planning :)

2000OO-based(!) theming,somewhat overridable.

2001Default markup in core provides more

scalability.

2002The well-known

theme() function appears.

2003Template-based

theming (xtemplate) to avoid string concatenation

(in some cases).

2005PHPTemplate arrives. Template variable overrides exist.

FormAPI and altering arrives in concept.

2007Theme registry.

Preprocess functions, .tpl.php file overrides.

2007hook_elements()

appears. "Structured" vs "rendered" data

bring together modern RenderAPI.

ALTER ALL OF THE THINGS

ALTER ALL OF THE THINGS

http://drupal.org/node/134478#comment-538674

Posted by bjaspan on October 15, 2007 at 1:39pm

"menu callbacks ought to return structured data, not rendered data"

<?php

// OLD

return theme('foo', $bar);

<?php

// NEW

return array( '#theme' => 'foo', '#bar' => $bar,);

hook_page_alter()template_preprocess_foo()

template_preprocess()template_process_foo()

template_process()

Templates can be overridden...

Preprocessors can be overridden...

Processors can be overridden...

Theme functions still exist...

hook_theme_registry_alter()...

by 2009Many APIs. Theme

system is brittle, inconsistent,

difficult to grok.

Based on what we’ve built…

What do we need?

What do we need? (1)

Template-based markup that can be extended and

overridden.

hook_theme(), template_preprocess(), hook

suggestions, theme registry, Twig (PHPTemplate).

What do we need? (2)

Abstracted, alterable structure.

Render arrays, hook_node_view(), hook_page_alter()

What do we need? (3)

Sensible, accessible, API.

theme(), drupal_render(), render()/hide()/show().

2012DrupalCon Denver Core

Convo, Twig initiative, yay!

2012-2013Twig conversion,Portland Sprints,

killed process layer, markup cleanup, yay.

So where are we going?

8.xKill concatenation 1757550

Theme system architecture 2004872

Theme registry service 1886448

theme() deprecation 2006152

PRESENT1. I believe the

biggest issue with Theming is a brittle

RenderAPI.

PRESENT2. I believe Render API must move to an

OOP design.

9.xRefactor RenderAPI

to be OO1843798

http://lb.cm/arrays-of-doom

What does might OO

RenderAPI look like?

Influential design patterns

BuilderDecorator

Builder

Builder pattern

Object creation is delegated to a series of steps, then

finally invoked.

This fulfills the data storage component of a

Renderable.

<?php

$car_builder = new CarBuilder();$car_builder->setDoors(4);$car_builder->setColor('red');$car_builder->setMake('ford');

$car = $car_builder->createCar();

Builder pattern

Builder-esque Drupalisms

hook_node_view()

hook_page_alter()

Decorator

Decorator pattern

Behavior added to object dynamically at runtime without affecting other

objects of the same class.

This fulfills runtime variable preparation.

<?php

class Coffee() { function say() { return 'I am coffee'; }}

<?php

class CoffeeDecorator() extends Coffee { function __construct($coffee) { $this->coffee = $coffee; } function say() { return $this->coffee->say(); }}

<?php

class Coffee_Cream() extends CoffeeDecorator { function say() { return parent::say . ' with cream'; }}

class Coffee_Sugar() extends CoffeeDecorator { function say() { return parent::say . ' with sugar'; }}

$c = new Coffee_Cream(new Coffee_Sugar(new Coffee()));

Decorator pattern

Decorator-esque Drupalisms

comment_preprocess_node()

mytheme_preprocess_node()

Getting markup1. Get data.-- START RENDER PROCESS --2. Define renderable.3. Alter renderable.4. Render renderable. A. Call theme callbacks. i. Call preprocessors. ii. Invoke template.-- END RENDER PROCESS --5. Send markup to client.

Disclaimer:Let’s not get hung-up on

implementation:)

Renderable definition<?php // D7/D8

return array( '#theme' => 'node', '#node' => $node,);

<?php // D9?

return new RenderableBuilder('ThemeNode', array( 'node' => $node, ));

Altering<?php // D7/D8 function mymodule_node_view(&$node) { $node->content['image']['#theme'] = 'foo';}

<?php // D9?

function mymodule_node_view_alter($builder) { $builder->get('image')->setBuildClass('ThemeFoo');}

Variable prepare (1)<?php // D7/D8 function template_preprocess_foo(&$vars) { $new_title = $vars['title'] . ' overridden by foo'; $vars['title'] = $new_title;}

Variable prepare (2)<?php // D9

/** * @file Theme class for foo.tpl.php. */

class ThemeFoo extends Renderable { function prepare() { $new_title = $this->get('node')->get('title') . ' overridden by foo; $this->set('title', $new_title); }}

MOAR

http://github.com/c4rl/renderapi

Discussion and planning :)

THANK YOU!

WHAT DID YOU THINK?

Locate this session at the DrupalCon Prague website:http://prague2013.drupal.org/node/1863

Click the “Take the survey” link