Drupal VS. Mambo 3
Technical & Architectural Differences
Now we come to the real meat of the matter. During our sojourn into the dark art known as Mambo SEF, we’ve necessarily become quite familiar with the internal workings of Mambo. To be candidly honest, it’s not exactly impressive.
Mambo is a very limiting design. Pretty much the only “hook” into Mambo’s core, to allow any significant third-party extension to Mambo’s base functionality without modifying the core files, is the SEF support. (A cynical person might argue that even this “hook” exists only for the benefit of a certain commercial SEF extension developed by a former core developer.)
When we originally designed Xaneon Extensions for Mambo, the most interesting aspect for us was to provide a general “core extension” framework which would allow multiple components to utilize XE2 to tap into the core without disturbing the SEF support or interface. Essentially, a “multiplexing” of the one and only core hook, for the benefit of all. XE2’s own code is very extensible, allowing other developers or site administrators to override functionality as they need to. Hopefully someone else will take this idea, or even our code, and run with it.
Drupal’s architecture, in comparison to Mambo’s, is like a breath of fresh air. First off, reading through the core code was a pleasant experience: it’s not only cleanly designed, and with extensibility constantly in mind; it’s also well commented and documented. The design is incredibly flexible from the view point of an add-on developer coming from Mambo: there is no need for separate “components”, “modules” and “mambots”, as one Drupal module can perform the tasks of each, and much more besides. There is a general-purpose, all-pervasive “hook” system in place, allowing modules to override functionality in the entire lifecycle of content objects (known as “nodes” in Drupal), as well as perform actions at certain points in the handling of page requests.
Application Programming Interface
In Drupal there is actually an API for modules to use; this is a very important point. One reason for the inconsistent quality of Mambo components, and the proliferation of non-standard user interfaces, is no doubt that there are no standards, or at least no significant high-level programming interface that would facilitate the creation of third-party add-ons. Essentially, to create a Mambo add-on, one needs to start from scratch and reinvent the wheel every time. It gets frustrating after a while, even though the developer may learn to refactor and reuse some of his code.