Pronounced "drupal-art", noun referring to Drupal code that is both beautiful and artistic.

We previously explored the idea that software is art, one of many creative disciplines. We examined art through the eyes of both the layman and the artisan, and meandered from traditional art to software art. We looked at pseudo code and glanced at PHP. I looked for beautiful code in Drupal core and concluded that Drupal's beauty is not in its code, but in its API's.

Relational Art

Without the relation the artist has with art (the time and attention that goes into the work), or without the relation the art lover has with art (the time viewing, collecting and enjoying the work), art would be nothing more than an object of clay, canvas, or cloth. We find value in objects, but appreciate beauty through connections.

I find the deepest beauty in relational art; paintings and sculptures that embed relations within the art object itself, mostly those that depict people in loving relationships with each other. Renoir’s Luncheon of the Boating Party is a great example, showing multiple interactions of people, pet, food, and drink.

My definition of artistic software embraces relationships. Software relates not only to users, developers, and maintainers, but also to data and external interfaces. Remember these relationships as we explore software art.

Object Oriented Programming

OO is all about relationships.

Drupal core reminds me of an OO C/C++ experience, reinforcing the thought that code can be object oriented despite use of a procedural language. When C++ was introduced, developers were abuzz discussing dubious commonalities linking diverse problems. Book publishing and pizza delivery became the same problem — workflows. I personally fought the switch to C++, arguing that it offered few new capabilities that couldn't be done by a well-written procedural language like C. What I didn't understand then — that I now know — is that I was already an OO developer. (This is not a knockdown of OO languages; OO has its advantages.)

Drupal core, before Drupal 7, was almost exclusively procedural. But it was also OO. Drupal modules could be thought of as class implementations of a generic web application: a theme is a class factory override of our generic web application's output. Drupal's hooks are a procedural implementation of class method overrides. Drupal took this a step further by separating the logic from the display, by creating a module system AND a theme system.

A FAPI Example

Let's look at one API that uses much of what I find beautiful in Drupal: the hooks, the theme separation, and — if you recall from my last article — PHP arrays. It even has a cool name! FAPI, short for "form application programming interface."

FAPI documentation mostly discusses the data. To create a new form, we create a function that returns the forms array and we instantiate the form using something like a page callback that uses drupal_get_form. Nothing special; not OO yet.

But as soon as someone wants to modify what you created, it becomes OO. While the documentation focuses on the data structures, it's really the ability to modify the data that makes FAPI so elegant. Create a hook_form_FORM_ID_alter() function and change the data; change the order of elements in the form, adding #weight properties; change the #access; hide elements; perform additional validation; alter or change the data on #submit. FAPI makes it easy.

I May Be Wrong

It's not the data. Well, maybe it is somewhat the data. The forms array is elegant; recursive elements and fieldsets are nice. But it's really the extensibility provided through hooks and handlers: It's the relationships that are special.

Drupal has an elegant OO, just not in the classical sense. I may be wrong now, just as I was wrong about C++ — and this is not an attack on those actively working on Drupal 8 — but I'm not convinced that objectification adds much. The test will be whether we gain more classical OO programmers to offset the less-trained, part-time developers we are likely to lose.