I have recently been testing open source MVC frameworks (RubyOnRails, TurboGears, Django) for an upcoming web application development project. Thus far Django has come closest to meeting my particular set of requirements and preferences, thanks in large part to its excellent documentation, its powerful and easy to use object-to-relational model, and its killer administration interface that is automatically generated from the model definition.
However, I have put these three ‘pure’ MVC frameworks on hold while I test out whether Drupal is going to meet my basic functional and technical requirements.
The main reason for this shift is that two local acquaintances, who are actively developing with Drupal, have been urging me to give it a try as a high-level web application toolkit. Also, the timing is right because in a couple of weeks Vancouver will be host to the Open Source Content Management Systems(OSCMS) conference which is offering many Drupal-specific sessions. This will allow me to test-drive Drupal in the next couple of weeks and to fill any knowledge gaps with OSCMS sessions and follow-up questions to the contingent of core Drupal developers that will be attending the conference. I can decide at that point whether to return to my Django prototyping or whether to blaze forward with Drupal.
I had considered Drupal as an option earlier but I had been swayed by all the buzz in the tech press and blogosphere about the new generation of open source MVC frameworks that are promising to improve the speed and quality of web application development.
Implicit in these frameworks is the idea that a Model, View, Controller (MVC) structure is the best design pattern for architecting web applications. A MVC architecture seperates a web application into three primary layers. The model layers abstracts a domain-specific data model and interacts with the data persistence layer on its behalf (usually a database but could also be XML or text files). The Controller interacts with the user through an interface (e.g. a webpage). The Controller receives information or requests from the user, routes these to the appropriate place in the application and returns the application’s response to the user. The View layer adds presentation templates (e.g. styles, themes, etc.) to the data that comes from the model layer, before it is sent back to the user interface by the Controller.
MVC architectures improve the development, scalability and on-going maintenance of web applications by dividing their critical components into seperate layers that can enhanced or exchanged without affecting the other layers (in theory). They follow the software engineering paradigm of seperating data persistence from application logic from presentation. Before the advent of RubyOnRails, TurboGears and Django, MVC type architectures had already been deployed successfully for a number of years (e.g. Apache Struts, Java Server Faces, WebObjects).
Since Drupal has been around a bit longer than the more recent MVC frameworks, it never thought to sell itself to new developers like myself as a MVC framework. It started out as website content management system and has grown over the past five years into a swiss army knife type toolkit for building websites that is host to an active community of contributors.
The main reason that I strayed away from Drupal earlier was that I had doubts about how well Drupal could serve as a toolkit for web applications instead of just websites. The main distinction being that web applications require the ability to configure custom data models specific to the domain of the application (archival description in my case). These data models must support basic one-to-many and many-to-many type relationships between the objects, something that all three of the new MVC frameworks do very well.
Resource Description Format (RDF)
Although Drupal provided the ability to define custom content types through its Flexinode module it has never provided the ability to establish relationships between nodes (its core content objects). However, that has recently changed. There are now a number of Drupal modules in the works that seek to address this shortcoming. The most promising and exciting of which is Dan Morrison’sRDF Metadata Module (particularly for the archivists, librarians and semantic web fanatics amongs us).
This module enables the concept of subject-predicate-object relationships (referred to as ‘triples’ in the Resource Description Framework (RDF) community). For example:
- ThisBlogArticle (subject) HAS AUTHOR (predicate) Peter (object)
- ThisBlogArticle (subject) IS PART OF (predicate) Archivmati.ca (object).
The RDF Metadata Module uses Dublin Core relation element as default predicates. It abstracts much of the heavy theory and syntax that underpins RDF standards and unleashes the power provided by these ‘rich’ relationships. In fact, by providing RDF triples support, Drupal stands to one-up the other MVC frameworks which only support one-dimensional relationships by default.
Drupal as a MVC Framework
I have yet to install and test the RDF Metadata module to confirm whether it delivers as advertised but from what I can tell right now, the RDF Metadata Module (or other upcoming Drupal ‘relationship’ modules/APIs) have filled the last missing piece of the puzzle that allows Drupal to be conceptualized as a MVC framework:
Of course, this diagram is a rough first draft from a newcomer to Drupal so I expect that it may be scoffed at by Drupal experts and MVC purists. However, I think that the core components are in fact in place. On top of that then is a big bonus (or bonanaza) for web application developers, like myself, that also need to package website cms features with their product. Drupal comes with an orgy of core and contributed modules which are integrated and extensible through what is proving to be a robust hook architecture.
Furthermore, Drupal is a lightweight (a 1.5MB installation!), flexible, and proven platform. Despite some forum chatter about needing an auto-install, Drupal is insanely easy to setup, both locally and on a hosted service, given that most of these are geared to support the Apache/PHP/MySQL configuration that Drupal requires (no messing about with FCGI or mod_python).
I still need to look into how well I can package, brand and deploy custom applications that are built on Drupal as their platform. I am also interested to see how well Drupal is going to be able to integrate AJAX support. One of my other previous complaints about Drupal was that the documentation and, as a result, the system architecture, was awkward to get your head around. However, it appears that there is a Drupal working group that is looking to improve the online documentation. In the meanwhile I have just purchased the Building Online Communities with Drupal, phpBB and WordPress book and it has helped to answer most of my questions and provided me with the background to draft the ‘Drupal as a MVC Framework’ diagram.
Now if only PHP was as clean, concise and geek-worthy as Ruby or Python…