Less code, more logic
Tue, 12/08/2009 - 07:14 — infojunkie
The aim of Drupal architecture is to implement the logic demanded by the application while resorting to a minimal amount of new code written. Modules are used as logic blocks that are assembled to yield the desired software structure that will acquire, store and display the site's content.
Coding for Drupal involves mainly creating reusable modules that implement specific logical manipulations of information. The crucial reason why this modular approach works in Drupal is that each module exposes hooks that allow other modules to extend its own functionality. Using this method, it is possible to assemble functions without writing a line of code, although the work involved is still programming: there are inputs, processing algorithms, and outputs.
To me, this is a genuinely new kind of programming, which a lot of people are comparing to Lego. I was a Legohead in my youth so I completely subscribe to this notion, and it's one of the reason why I love Drupal.
However, we haven't reached a completely code-less environment yet. Application-specific code that still needs to be written consists of:
- The theme, which is one of Drupal's weak points (not that it's been solved better in other frameworks AFAIK)
- Business logic that is usually not reusable. This code tends to end up in the database (e.g., blocks with PHP code) which is even sadder in terms of configuration management.
Of course, it's clear that code is still needed to build the modules. But it's important to differentiate between module development, which is a community-wide activity and thus benefits the whole Drupal ecosystem, and application development which is a client-specific activity. Further, these two activities are carried out by different types of people: PHP programmers for the former, and site architects for the latter. The skills and mindset needed for each are different.
I'd like to close this drulosophical piece by proposing a new analogy for Drupal development: the genetic code. Modules (and the theme) are genes that make up a site's DNA. The server is the cell. The Web is the living organism :-)
"There is a module for that" by Karim Ratib is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.
Drupal is a registered trademark of Dries Buytaert.
Comments
Thanks for commenting about the versioning problem and possible solutions. In each project I've been involved with, the team had a slightly different approach to versioning the configuration and non-file-based logic. I'll very likely write much more about this issue.
"This code tends to end up in the database" There is so much emphasis on doing things with Views, but I see this as much like the above mentioned prototyping stage, which may be better converted to module code if the work rules (cost, time) allow it. And this "code" also ends up residing in the database, but at least will eventually (hopefully) be automagically converted.
Breaking views out to modules is a performance optimisation rather than a configuration deployment solution. It has also become far less useful since views 2 which improved views query performance.
Views already provides deployment tools which produce versionable output. You would only enable the views GUI on a dev environment and use this to build views which are added to your downstream systems using views built in import/export.
The main issue is that your dev database needs to mirror live as a view may refer to specific node or taxonomy ids. This is an example of how the conceptual division of configuration and content is artificial and not really helping us. Any complex node type (e.g. feeds) or taxonomy for example form part of the configuration but are also content.
This is handy while rapidly prototyping however; ideally you would create a module for your php code outputting a block or a compromise would be to put just a call to a function in the block.
Either method allow you to keep your code in a file which can be stored in a code repository.