Drupal's basic building blocks - the search for core
I am a sucker for software engineering / architecture debates. Too many years in academia are to blame. We had the luxury to debate such issues endlessly. In particular, I am interested in the fundamental architectural choices given the implications they can have on a system both on a theoretical level as well as the practical implementation level.
It was inevitable, therefore, that the current debate in the Drupal sphere would catch my attention. The smallcore movement promotes the benefits of and advocates for a flexible, decoupled, core that allows one to more easily construct targeted, tailored Drupal distributions.
Before delving into the specifics of this I think it is worth pointing out that there are at least two issues being bundled together and it is important not to confuse them.
On the one hand, there is the pure architectural debate about what is the core of Drupal. What is that minimum subset of functionality that still makes some infrastructure identifiable as Drupal infrastructure?
On the other hand, there is a perception/marketing issue about how should Drupal be presented. Is it a framework, a CMS or some other sort of complete product - or both at the same time?
I am not going to touch on the latter as a) it is not really my strength and b) I don't talk to nearly as many stakeholders as others do. So I defer judgement on the latter to more knowledgeable/involved people.
It is also fair to add that there is at least a third issue - one about project management and being able to develop different parts of Drupal at different speeds. Again there are far more capable people to handle that one.
Finally, I should add that from my point of view was is being debated here is not whether Drupal should have a decoupled and flexible core. I think enough years of engineering in general and software engineering in particular can answer that one for us. Robust, decoupled, reusable, etc are all things you want to have. I realise that does not mean that the debate is done and dusted. However, I am not going to focus on justifying why you need a flexible core. Let us assume for a minute that we are past that and try to answer the question of what are the pieces of a Drupal core.
The Drupal Way
I want to focus on the basic issue of software architecture and what is Drupal's view of how websites (or web applications) should be build. That goes to the core of question (...see what I just did there?).
So, What makes Drupal, Drupal?
Not a CMS
When I first started out with Drupal I would answer that by saying Drupal was great because you have this very abstract notion of a node as content. Nodes have access to a range of services relative to content management from commenting to versioning to rating. Use nodes and you get a bunch of stuff for "free". In addition, you also have taxonomies as a flexible way of categorising content. And that for me made it a CMS that I clicked with. But those are CMS issues - not framework/core issues.
Not the community
As I learned more and learned how to add functionality to a Drupal site I then got excited about the number of modules and the community. That was very 'Drupaly' in its own way and again I clicked with that. Hang around Drupalers for more than five minutes and someone is bound to say the famous "There is a module for that..." phrase. And more often that not it is absolutely true. However, even that is not an architecture thing. It is a community/culture thing.
So once you take the modules away and you take any CMS specific notions away what is left?
Is it user management? Access control? The Field API? Semantic Web-iness via RDFa? Caching? Languages? Search? The Next Generation Database Layer?
These are all great aspects of "Drupal The Infrastructure", but they don't speak of Drupal the Architecture in the most fundamental way possible. They don't describe Drupal's view of web application development.
I believe what best describes Drupal's view of web app development are hooks.
It's the hook stupid
Yes - hooks!
I mentioned earlier that if you hang around Drupal people long enough you will hear the famed "There is a module for that...". Stick around some more and you will hear "There is a hook for that...".
Hooks are a deceptively simple but extremely powerful way of modifying your application and adding or removing functionality.
Crell - in a great post on smallcore - talked about additive or subtractive systems. Taking that notion slightly out of context for a second, hooks really allow you to do both to Drupal. You can let Drupal know of your intentions, intercept a flow of actions and have your say about what should happen next, or you can be notified of when events take place and react to them.
Drupal 7 has 207 "official" hooks functions - and I think that is great. Those are 207 ways to react to what Drupal is doing through simple PHP functions. You don't need any complicated setup, you don't need to know everything about every single aspect of Drupal to use one hook. You just need to understand your problem and the hook that can help you with it.
You then also have the whole hierarchy of overrides in templates - I view those as a type of hook as well. They belong to the family of Drupal things that say: "Look, something's happening - you can change it or you can do something else because of it. You can also just go have a beer because Drupal will mostly take care of things!"
The "cool" frameworks like Ruby on Rails and Symfony and Cake, etc all show you how you can have a blog in 10 minutes through a screencast. Well, the Drupal version of that screencast is that you can have a blog in 1 minute. But you can have the blog you really want in another 5 minutes through hooks and templates.
Sure, you need to find out about them. You also need to learn how to use them effectively. But that is really a documentation/education problem. Remember, here we are having a discussion on architecture - we don't allow real world issues like documentation and marketing stand in the way of great ideas!
Now, coupled with hooks you need a way in. That is where the menu system comes in.
Gateway to Heaven
Menu is one of the biggest misnomers ever - it really is Drupal's routing framework. It simply carries the name menu because originally it handled menus, poor thing. Nowadays, it does much more - but they all still call it by its kindergarden name.
Menu is the piece of functionality that decides what to do based on what is coming in through the URL and allows you to interact with it. By the way, It is also has a hook for you - hook_menu().
Again, it is a very powerful system and a very simple one. Just as it should be. The menu system is a little micro-framework in and of itself. It allows you to easily and quickly define what URLs your application can handle and tell good-old PHP where to go get the stuff it needs to get in order to do what it needs to do. There is a great white paper on the menu system by Robert Douglass here.
And that is it. Or not.
There are a couple of more things. This is about what Drupal is not. Which, in some ways, is just as important.
Enough with the MVCs already...
Drupal is not an MVC architecture. That is great. If you have to identify a Drupal pattern the Presentation - Abstraction - Control (PAC) pattern is more suitable.
Indeed, Drupal is a full blow multi-agent PAC. This pattern is more honest about things in that it eliminates that line between the Model and the View taking a more modular and flexible approach. It accepts that there are several abstractions or application components that users interact with through presentations managed by controllers.
PAC agents (a trio of presentation-abstraction-control) are active components that react to changes in their environment (in Drupal they find out about stuff through hooks mostly) and can also have dialogues between themselves (e.g. one module uses another module's hooks).
An MVC model where you ideally map what is on the screen to what is in the database only holds for basic examples (again those famous screencasts...). Complex applications then often move on to the more generic multi-agent PAC approach even though they don't indicate that.
Drupal, with its modular approach and hooks removes the mental step of having to realise that MVC in its idealised form generally never exists. Instead every module is a little independent entity that interacts with various other agents based on a semantics defined by the Drupal framework through hooks and APIs.
Slight disclosure here - my PhD thesis was on Models and Infrastructures for Agent-Based Systems. Although I worked in the distributed AI field I kind of like agent-based approaches to solving problems.
Drupal is not a pure Object-Oriented System
Don't get me wrong. I spend many happy years OOing, and I think it has helped the cause of software engineering considerably. However, you can easily fall into a trap of going overboard with objects and interfaces and abstract classes. Drupal, and especially Drupal 7, has plenty of OO components. But its non-OO roots means that it can take it easy where you don't really need to go the full-blown OO way. It is OO where there are real benefits rather than just because that is how you are supposed to build things.
They all lived happily ever after
Drupal's hook approach, the independent modularised system, together with route handling presented in a simple but powerful way and immediately accessible to developers are the architecture aspects that make Drupal a great system to build on. These are the building blocks of the Drupal Theory of The Web.
The sensible approach, the don't follow the crowd (e.g. MVC or full-blow OO) mentality are the traits that keep things cleaner at times.
For me, the way forward for Drupal at this level, my smallcore and where I hope to finally get more involved with core development, is in making sure that Drupal remains true to the principles of all of the above, improves on them, presents them better and provides the most flexible possible basis to build great things on top of it.
So that we get much more of the tons of cool functionality that Drupal offers now.
Many thanks to Robert Douglass for reviewing this post