A metaphor for Drupal module's inner workings

Question

What is the best application workflow metaphor for Drupal module? In PHP frameworks we think MVC-style. How do we think inside Drupal?

Asumming I am writing some user-oriented module like Shop, Catalog or Forum. As far as I understand there are no or few MVC based modules. Should I generally treat Drupal modules (as sub-application) as a number of screens connected via forms and hyperlinks or there is a better way.

My question may be a little bit speculative, but I hope someone will share my intent to think models, not just "scripts".

Answer 1

This is a bit of a high level question, but I will have a stab.

Drupal is a content managment framework, there is a good overview here.

Drupal is bassed on some object orineted principals. It has seperations of concerns, much like MVC. There is a database abstraction layer, a logical layer and theming system.

When programming a drupal module it is often advisable to make use of one or more of the hooks available. This will allow you to tightly integrate your code into the drupal system. There is a lot of functionality built into the core, which you can leverage in your modules. Making use of these will reduce the code that you have to write as well as making your code more drupalish.

Answer 2

Modules in drupal are best thought of as a collection of functions (implementation of drupal's "hooks") which are called when certain "events" happen in the engine. Those are not strictly user events, but also, for example, stages of loading (before loading a node, after loading a node, etc...), or checking (the engine is checking for permissions, do you want to add some?).

In reality, hooks are functions that extend drupal functionality, so you add your own behaviors to the drupal-provided ones. Drupal will then call those hooks in the appropriate time, to allow you do perform your actions.

So there is no tight connection with forms or pages, and there is no relation to anything like the MVC model... as of version 6, drupal is not object-based.

This regards the strictly drupal part. Your module is build on top of this, but it may use whatever architecture you wish. It may be object-oriented, and it may use MVC or any other pattern.

Answer 3

The Drupal hooks are called Listeners, or Observers in most OO languages. Though they technically folluw that pattern, don't expect the polishedness and maturity you will find in most OO languages and environments. Drupals hooks can be extremely inconsistent, limited in use or far too broad in use.

Listeners, hooks, are the core Architectural principle of about everything in Drupal.

Answer 4

Presentation-abstraction-control (PAC) seems to be the closest match of a pattern describing Drupals general approach of things, but I guess this is more or less accidental ;)

The hierarchical organization of (more or less) independent PAC triplets can be roughly mapped to Drupal modules being more or less independent agents under a common roof, doing their part in all three areas (View, Controller, Model/Abstraction).

Model-view-presenter also defines some aspects that can be found in Drupal, especially the deviation from MVC in that the View does not take its contents directly from the Model, but from the controller, so that the flow of information is strictly View<>Controller/Presenter<>Model.

But the separation of concerns in Drupal is (as of yet) quite informal and depends a lot on the coding discipline of the developers, therefore being constantly on the edge of breaking down completely (there are many modules putting plenty of logic into the theming layer, so more or less into the view).

That said, not enforcing the separation to strictly seems to be one of the reasons for Drupals success, as it allows a wide range of people with very different backgrounds to contribute without having to be trained developers. For example, a HTML/CSS Guy with a little knowledge of PHP can achieve quite a lot of tweaking and added functionality from within his templates alone, without having to implement full blown modules. If what he did is of general interest, it will sooner or later evolve into a more formal structure/module by other people picking it up. Same goes for the wannabee, hobby and beginner developers - they can accomplish their goals even without really understanding whats going on, so their ideas for functionalities get added to the contributions and can be refined, if they meet a general interest.

So far this has worked pretty well - the core of Drupal got more formal (or less scriptish ;) with every major release while still keeping the flexibility for add ons - let's see if this will hold up in the future ...