Login

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".

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.

[Presentation-abstraction-control][1] (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][2] 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 ...

[1]: