So, I've been thinking that for a while our rendering pipeline kinda sucks.

At the moment, we use Drupal's theme layer in a slightly hacky way to render our files. Essentially our views display plugins ask our style plugins to render their header's, footer's and middle's to a string, and then our display plugin writes those strings to a file. Our style plugins directly invoke the Drupal theme system to turn views' data structures into strings to write to the file.

Drupal's theme system was really designed for generating anything other than HTML, and so while we get a lot of nice stuff, it ends up being really messy. We do some stuff in preprocess functions, we have some shared functions that get called by multiple preprocess functions, and we finally have the .tpl.php files that turn the data into strings.

This limits the sort of files we can export, and although promising flexibility, I think makes it confusing to say, slightly alter the output of an XML file, adding a schema definition to the file, for instance.

Also the current theme based rendering system means that we're not unit testable, and we're tightly coupled to Drupal's theme system (of course).

I propose that we write a new rendering pipeline, that looks something like this:

  • A hierarchy of classes that can be solely about taking some data and writing it to files.
  • Simple method calls to turn data from Views into data on disk.
  • Documented and easily extendable classes so that if people want to change the output they don't have to work out what magically named files to create and work out what variables are available, but that it's all obvious.
  • Options for the files output themselves can be pushed down into these classes, so at the moment, there's an effort to allow wrapping the XML data in CDATA tags, this could be entirely configured in the rendering pipeline, and our Views plugins just display a UI for that.
  • An awful lot of this is going to be doing what Views style plugins are doing anyway, but there's an important separation: We don't have all the associated baggage of the Views style plugin, and we can be unit testable I think.
  • This should allow doing things like using a PHP extension to write a 'proper' XLS file to disk, because we can actually write non-string data much more easily.

Anyway, I'll let this sit in my head for a while, and try to come up with some more information too.