Limitations of the Drupal theme layer
With the release of Drupal 6, phptemplate put a triumphant end to any alternative templating systems in Drupal. We've reached the holy grail of theming -- all that remains is to replace in-code theme() functions with preprocess hooks and churn out hundreds of template files, right?
Not so fast. In this session I will argue that the Drupal community needs to keep its eye on the ball -- true separation of data from presentation -- and argue why there is still more underlying work to be done.
Part 1. Three errors designers make in their mockups because Drupal's theme system just can't do them well.
- moving something out of its vertical theming stack (why can't the node links be in the sidebar?)
- changing the formatting of a core element (why can't that blog archive block be a dropdown?)
- expecting visual consistency across different modules (why doesn't a node look the same as an item in a views list with exactly the same fields?)
Part 2. What's the underlying problem?
A failure of separation between data generation, representation, and presentation. I will show why the 3-part distinction, rather than the usual 2-part distinction (data + presentation), is critical to getting a grasp on how to make our good theme system great. I will explain why Drupal needs to formalize a data representation layer where the data format is independent of the desired markup.
Part 3. Why rule-based templating wins and why <font> tags suck.
I'll take a look at another project that got it right: Symphony (http://www.symphony21.com) uses XML and XSLT to separate its data representation from its data presentation. I'll then look at the main requirement of a solid templating system: rule based templating and compare it to the shift from presentation based markup to semantic markup in the XHTML/CSS sphere (e.g. why we stopped using tags). I'll examine the strengths and weaknesses of XML/XSLT and then run through other possible approaches to rule based templating that may fit Drupal's style and culture better.
Part 4. Where do we go from here?
An outline of the major direction the theme layer should take, and what we should expect to gain from such a shift:
- Greater theming flexibility
- Improved standardization of markup across modules
- Greatly reduced costs of having Drupal generate: RSS, RDF, XML, CSS,
plain text, etc. etc. etc.
I will also take a brief look at how the main component building tools in Drupal blocks and panels will affect and be affected by a rule based system.