Looking for Archivematica the software project? see: archivematica.org


archivemati.ca header image 1

Drupal as a MVC framework?

January 21st, 2006 · 32 Comments · System Architecture

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.

Model – View – Controller (MVC)

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’s RDF 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:

Drupal 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…

update: see version 2 of the diagram in comment#6 below.

32 responses so far ↓

  • 1 Boris Mann // Jan 21, 2006 at 8:27 pm

    Fantastic that you wrote this. Saw the post on Drupal.org, too. Rather than flexinode, you’ll want to check out the Content Construction Kit.

    The RDF metadata module looks very interesting, but none of it has come over to play at Drupal.org CVS yet. We should definitely schedule some time to look at it in more detail in Vancouver with the other CCK folks — most of which are attending, I believe.

  • 2 John VanDyk // Jan 21, 2006 at 8:42 pm

    Peter, I look forward to meeting you in Vancouver. As Zacker was saying, Drupal has great potential in the semantic web space.

  • 3 Reinhard Knobelspies // Jan 22, 2006 at 1:48 am

    Great article. We have tested django for the same reasons and come to similar conclusions. The admin interface of django is astounding. TurboGear now added its own sleek admin browser called Catwalk. Fortunately for Drupal these frameworks don´t offer nearly as much functionality yet as Drupal offers with modules already available today – unless of course you want to shell out 25.000 $ for the Django-based CMS Ellington As Boris said, CCK will be a cornerstone for Drupal in that direction. However I think the most critical and competitive part will be the visual implementation of CCK for data modeling and administration.

  • 4 Steven Wittens // Jan 22, 2006 at 2:40 pm

    Interesting… I’ve never really thought of Drupal as a clean MVC architecture.

    Some notes:
    - Path.module is not really a ‘controller’, it only provides a UI for making path aliases. The real mapping of a (non-aliased) path to its callback is done by the menu system in menu.inc (whereas menu.module is only a UI for creating custom menus and menu items).

    - While phptemplate is usually used
    for theming, it is nothing but a passthrough from Drupal theme(‘foo’) functions to foo.tpl.php files, along with some minor tweaks. PHPtemplate is just one way of getting the HTML output.

    - The database abstraction API in Drupal is not a model in any way. It merely provides SQL-flavor agnosticism (i.e. a standard way of doing ranged queries, of passing in binary data, of juggling multiple connections, etc.). The link between a data object and its storage in SQL is done in the node system and is not really abstracted or dealt with automatically (like it is in e.g. Rails).

    As far as Ajax support for Drupal goes, personally I find it very difficult. Almost all the Ajax stuff being done today on the web is aimed at very specific functionality in specific contexts.

    But, with a system like Drupal we have to maintain the flexibility of the hook and node system in the JS realm. This is really hard if you don’t want to pepper your source with inline script tags and on-attributes. And avoiding browser bugs is hell if you don’t have any guarantees about the markup and styles in the theme.

    Drupal’s flexibility also means that we can do very little on the client side (it all depends on what modules are enabled and how they interact), which means that usually we have to restrict ourselves to so-called ‘Ahah’ (asynchronous http and html). And at that point, there are not that many cases where asynchronous loading provides a significant usability benefit.

    Of course, this only applies to the Drupal system on its own. Once you start building your own sites with it, a lot of these concerns fade away. That’s why I think for Drupal Ajax will remain mostly in the realm of 3rd party hacks/snippets.

  • 5 Mark Jordan // Jan 22, 2006 at 4:49 pm

    Boris, the Content Construction Kit stuff looks very interesting. It might be a better way of implementing a simple hack I did to create a prototype that included a metadata record and page-image content (a handwritten letter). I used flexinode to create the metadata and added some PHP code to handle the page turning. If the CCK is going to be ready for production in conjunction with Drupal 4.7 I’ll take a look at it then in the context of my ideas for using Drupal as a simple digital library CMS.

  • 6 Peter Van Garderen // Jan 22, 2006 at 9:34 pm

    Thanks everyone for your feedback, both here and in the Drupal forum. It’s added yet some more depth to my understanding of Drupal.

    Learning about the Content Construction Kit (which will replace the Flexinode module) is obviously some critical information to understand the direction of the Drupal architecture.

    I also found JonBob’s write up on Drupal from an Object Oriented perspective to be very useful in getting a better understanding of Drupal’s inner workings.

    Pure MVC?

    I think one thing to remember is that MVC is a design pattern and for each platform that claims to be a MVC platform there will always be some debate about how completely it meets that pattern. Django, for example, considers itself more of a Model, Template, View (MTV) architecture.

    In the end, I don’t care whether Drupal is a MVC platform or not. I just care whether its the right tool for the job.

    For me personally this is just a useful entry point to try and understand the Drupal architecture better. It was a natural approach given the time I have just spent thinking in MVC terms with the new web development darlings (RubyOnRails, TurboGears, Django).

    Version 2

    I have since updated the diagram to reflect the feedback and new information that I received.

    A few notes on version 2:

    - For each of the three MVC layers, I am considering all of the Drupal modules or components listed there together to provide the Model, View, or Controller functionality. Therefore, I have left the path.module in the Controller layer because I think it still plays an important part (supported namely by menu.inc) in mapping permalink URLs to the corresponding Drupal application logic. The other MVC frameworks put a lot of stake in this (permalink aliasing).

    - For the same reason I have left database abstraction API in the Model layer. By itself it doesn’t provide a ‘model’ but, used in conjunction with the modules that let us define custom data models (e.g. Content Construction Kit, Taxonomy) it provides a object-to-relational mapping function which is the cornerstone of the other three MVC frameworks.

    - From what I have managed to read about the Content Construction Kit, it is not addressing the ability to establish arbitrary relationships between custom nodes (someone please correct me if I am wrong). I still think that providing RDF triple support would be a unique and incredibly powerful way to do so. Therefore, even though it is not an official Drupal module, I have left it in as a key piece of the model layer. If we don’t have the ability to establish relationships between nodes and custom content types, we don’t have a Model layer. This means we wouldn’t have a MVC architecture and, more to the point, Drupal would be of no use to my project.

    Drupal as a MVC Framework - version 2

  • 7 Boris Mann // Jan 23, 2006 at 6:56 am

    I love this party we’re having in Peter’s comments :P

    Mark, I saw your page turner. CCK has come together a bit more quickly than expected. It looks like it may be live in the 4.7 time frame, especially if more people are interested.

    The first question about your page turner is if your letter should be one node or many. Current thinking around this is that every file should actually have an associated node. Your letter would then have a node that represents the entire bundle, and you would relate multiple sub-nodes to it in a number of different ways.

    Page turning would then be implemented across nodes. Here’s a link to next/prev links using taxonomy: http://drupal.org/node/45050

  • 8 Peter Van Garderen // Jan 23, 2006 at 7:06 am


    Glad to host this little get-together.


    • “Your letter would then have a node that represents the entire bundle, and you would relate multiple sub-nodes to it in a number of different ways.”

    What are the different ways that you can relate nodes to sub-nodes?

    Obviously I am driving at the question of whether/how relationships between nodes will be handled in the CCK.

  • 9 Peter Van Garderen // Jan 23, 2006 at 7:41 am

    UPDATE: It turns out that Felix (aka the_undefined) has already been looking at how to bring MVC concepts to Drupal. His solution is to build models using CakePHP (a PHP-based MVC initiative in the RubyOnRails vein).

    A couple of initial thoughts:

    1) Depending how complex the models get (and therefore how many of its objects need to be loaded into memory), this could introduce performance problems.
    2) More significantly I think that pursuing this path could begin to split the Drupal platform in half. In this scenario (which, BTW, might be an excellent solution to Felix’s own business requirements) Drupal could simply become a CMS add-on to a MVC application built on CakePHP. I still think providing the ability to define custom data models within the Drupal core (e.g. using CCK) would be the preferred route. It would appear that Drupal already provides the View & Controller layers.

    The open questions I still have are:

    1) how well CCK is going to be able to support relationships?
    2) how well Drupal is going to be able to support AJAX? I think that providing AJAX widgets is going to be a pretty standard requirement in any newly developed web applications. As with the other new MVC frameworks, CakePHP is moving rapidly to support it. However Steven’s feedback in comment#4 above casts some doubts over how much AJAX support can be provided in core Drupal. As he notes, however, there is still lots of flexibility to build it into custom Drupal applications that extend the core. Maybe any applications Felix’s builds with his CakePHP integration would fit into this category.

  • 10 mikepk // Jan 23, 2006 at 7:58 am

    I’ve tried to simplify the creation of ajax style applications with my YAJAF! javascript library/Ajax framework. I think I’ve come up with a way to build on the tacit knowledge of GUI programmers, creating an extremely flexible library/framework, and making it all very ‘natural’ to use for programmers of traditional object oriented languages. I haven’t released it yet, and I’m trying to see if there’s any interest in doing so, check it out and let me know what you think.

  • 11 Boris Mann // Jan 23, 2006 at 8:11 am

    Aarghh! Please, no more AJAX comments! Drupal 4.7 has lots of auto-completes for data built in, but that really doesn’t matter. AJAX is an interaction design issue, it occurs at the template layer, is problem specific, and is *trivial* to implement.

    Correct data models and other things we are discussing are much, much harder.

    For some things, a full-blown embedded Flash application will kick AJAX’s butt six ways from Sunday.

    CakePHP…yeah, it will split Drupal. Not needed. We can do it with “native” Drupal.

    I don’t know if CCK will support relationships. The relationship API talk at OSCMS is likely going to be well attended.

    Although I get all icky when I think of RDF, the data model is good, and the code that you referenced off site is a great start. I will laugh if Drupal ends up becoming a great RDF data store/manipulator!

    Here’s some 4.6-era AJAX:
    * live example of map interface (maps code)
    * source code from Colin of helper scriptaculous module

  • 12 Mark Jordan // Jan 23, 2006 at 9:20 am

    Boris, the page turner was just a proof of concept, designed to illustrate one type of document/content handler. For my particluar application, there could be multiple types of content, such as a single or multiple media files like .pdf or .mov, or multiple HTML or XML files that comprise a resource. Because I was using flexinode to structure the metadata (and included the PHP page turner in one if the fields), I modelled it using a single node by default. If using multiple nodes is more druplish, then that’s the way I’d want to go.

    In a multi-node model, some documents would act as the “root node” and get a metadata record, while some of the children would also be relatively autonomous and therefore get their own metadata record. For example, a newspaper (Gotham Times) would get a record, each issue (Dec. 15, 2005) might get its own record, and each article (“Batman is an introvert”) might get its own as well. This is where the RDF module would be useful since it can handle relationships like HasParts and IsPartOf.

  • 13 Tesla // Jan 24, 2006 at 4:06 pm

    A couple of items will make your logic easyier to work out.

    MVC is just a base for moving into page controller or front controller. It is important to note this as Drupal is more of a front controller since the characteristic of a page controller means that it can be in multiples and fit in with different types of data being called on a per page basis with heirarchy. Drupal does not do this. It behaves more like a front controller.

    Missing in your controller section is the common.inc which is needed as the common base class. In this case not OOP so it is a substitute that acts as a base class. Using this will underline why frontcontroller is the closer pattern.

    This is an important distinction from Ruby on Rails which follows the page controller pattern.

  • 14 Robert Douglass // Jan 25, 2006 at 12:45 am

    Talk about showing up late for the party…. =)

    Peter, great article, fun discussion, glad you found the book useful, see you in Vancouver!


  • 15 Boris Mann // Jan 25, 2006 at 9:24 am

    FYI: http://coders.co.nz/drupal_development/?q=node/61

    Note the phrase “import the entire Dublin Core Schema”. This is for 4.6, and will be quite a bit of work to port to 4.7 (which is where new development should happen), but it’s got some pretty incredible relational/metadata features.

  • 16 Dan Morrison // Jan 25, 2006 at 9:17 pm

    Hi All.
    largely due to the interest sparked by this little suggestion (I dread to think what would happen if I was pinged by one of the big semweb blogs) I’ve got around to actually establishing the project I proposed 2 months ago.

    Drupal.org is now hosting a workable release of “RDF Metadata” (re-christened just “relationship.module”) at http://drupal.org/node/40611

    There’s a big write-up there on what it does so far, a sandbox (obviously broken in places) is at http://coders.co.nz/drupal_development/?q=node/8/edit

    Recent work has been on supporting dynamic selectors expressing the ‘domain’ and ‘range’ of different predicates. It’s NOT AJAX (yet) it’s just javascript population of select boxes ;-) but the forms do LOOK sorta dynamic.

    I’m unaware of the CCK initiative, but I suspect we are approaching things from a different angle.
    Anyway, now the code’s up, I’ll start getting some feedback. Already in discussion about the cross-over with links.module.

    Personally, I’m still hazy on what MVC means in practice, but that’s just because I’ve been reading too many W3C OWL Specs this month. My brain is full. :-/


  • 17 Boris Mann // Jan 25, 2006 at 9:27 pm

    Dan — awesome to see your stuff land in Drupal CVS. It’s going to get a bunch of pounding.

    I wouldn’t actually worry too much about the current codebase…the immediate desire will be to see a bunch of it in 4.7, where AJAX-y goodness can be added.

    Also, you should absolutely pop into #drupal on freenode and try to connect with the CCK mavens. Basically, all content types will be composed of semantic fields. New modules might produce new semantic fields and/or new views.

    I have several clients that are very interested in what you’ve put together, so you should get some real live feedback soon.

  • 18 Bèr // Jan 26, 2006 at 7:12 am

    You really should have a look at views.module. It is great, and brings Drupal a lot closer to being a real MVC.

    In the mean time, however, I think it is too early to really call Drupal an MVC. Its still a bit of a MVS (S for spagetti). The view layer is very much tangled into the data and model system. Too much, to really call it a layer yet.
    Drupal often calls views (theme functions) inside data models, then parses that and then pushes it to the views layer back again. Or it calls views, in views in views in…. It also has a lot of logic on the views side, we have some really, really complex theme functions.

    Drupal is on the right track, IMO. But is not a real MVC yet.

  • 19 Peter Van Garderen // Jan 26, 2006 at 10:00 am

    This is turning into quite a party. It’s almost like I have houseguests now ;-)

    Seriously, this discussion is very useful to me and I thank everyone for their input. I am learning a lot about Drupal very quickly this way.

    Tesla, thanks for pointing out the difference between the Page and Front Controller patterns. My simplified understanding is that a Page Controller uses a centralized model for receiving, routing and returning requests whereas a Page Controller uses a decentralized model where every view may have its own controller. As you point out, this would mean that Drupal fits the Front Controller pattern as it uses a common include file (appropriately named common.inc) to route all sessions (along with menu.inc?). On top of that, common.inc is not an OOP-type base class that instatiates new objects to manage each session.

    Dan, thanks for submitting the relationship (nee RDF) module to the CVS. Mark and Boris have already been ‘pounding’ it. Unfortunately, I have had to put my Drupal testing on hold while I am trying to complete a couple of other consulting projects right now. I am also moving house over the weekend so I may not get around to testing my theories and putting these modules into action until late next week, which is very frustrating given the excellent information and tips I know have.

    Bèr, thanks for pointing me to the views.module. My application will have to present search result lists and browse lists so the views.module sounds ideal for that.

    I would agree with your assessment, Bèr, that Drupal is on the right track but not quite a true MVC. I think using ‘S’ for Spaghetti is probably a little too derogatory although fairly descriptive (I am guilty of using the same adjective in a previous post). I also followed your URL link back to your own website and discovered that last month you had already posted several thoughts on Drupal as a MVC framework (stirred on by experimentation with RubyOnRails like myself). Your post adds yet more context and some excellent detail to this larger discussion.

    After all that though, I would like to reiterate that I am, in the end, not really concerned whether Drupal is by definition a true MVC or not.

    I am mainly interested in determining whether Drupal provides me with the functionality and features I need for my project and that it is robust and flexible enough to sustain my application going forward. It’s starting to look that way.

    Coming at the Drupal architecture through a MVC lens has simply given me a very thorough and productive way to analyze it. I am not suggesting for one minute that Drupal now needs to go on a heroic mission to convert its architecture to a true MVC pattern.

  • 20 ikhnaton2 // Feb 26, 2006 at 3:50 am

    Interested article. I’ve been asked to develop a web application and thought of two alternatives: using MVC framework or using Drupal CMS. It’ll be great to interpret Drupal as MVC framework.

  • 21 Rick Vugteveen // Mar 17, 2006 at 12:21 am

    Drupal is actually quickly molding into a MVC architecture. CCK allows for a flexible database creation tool, while Views controls the presentation of data. These new core modules change everything and make a lot of other, old approaches obsolete. Very exciting times for the project…

  • 22 Harro! // Nov 17, 2006 at 10:36 pm

    When I look at drupal code, Its seems pretty “complex” with “hooks” here and there.

    The MVC model is very much simplified design. Zend has thrown its weight behind this model through its http://framework.zend.com

    The reason for Zend to do this is to create a suitable structure for the PHP community to create maintainable, scalable, and possibly object-oriented applications using PHP.

    As mentioned Path.module might act as the controller.

    However, the “view” is also a challenge. Remember that a view consists of many widgets (drupal modules) which in themselves are mini MVC apps.

    Then throw in themes and language translations? :) Then consider integrating Mashups? Now you will see how having the MVC at the start will help vs unstructured sphaghetti.

    Unfortunately, the MVC stucture will generate alot more code. :(

    Have fun. :)

  • 23 kourge // Jan 29, 2007 at 10:05 pm

    With the recent release of Drupal 5, there are more bundled Ajax functionality provided by both the updated architecture itself and the bundled jQuery framework.

  • 24 Christian Pearce // Feb 5, 2007 at 12:21 pm

    Has this forum been continued elsewhere? Since 5.0 released seems a fair amount of modules are still catching up. I want investigate the relationships module with using CCK, but am having a hard time wrapping my head around all of it. Is there any tutorial or documentation planned to provide an easier understanding?

  • 25 Peter Van Garderen // Feb 5, 2007 at 12:32 pm

    Hi Christian,

    I am not sure. The lack of adequate documentation that let me wrap my head around the Drupal architecture, its various modules, and in particular CCK was one of the primary reasons I wrote this post last year and was also one of the main reasons I decided not use Drupal for my projects in the end.

    I have been using the Symfony PHP MVC framework for almost a year now and I love it. The documentation is especially strong.

    You’ll have to check back with the Drupal community at Drupal.org for the answer to your question. I did find them to be a friendly and generous bunch and still keep in touch with some of them.

  • 26 fora // Feb 6, 2007 at 1:14 pm

    This is a rather ambitious task I hope you can figure out the hows and finish it to a good result. RoR is great and easy to use for existing ruby programmers. greets, rick

  • 27 archivematica » Django it is then // Jun 11, 2007 at 10:47 am

    [...] I have given Drupal an honest and thorough examination but there are still too many gaps in its ability to define and manage custom domain models. Drupal is a great, if not the best CMS out there. Also the community of developers are very cool and motivated. Drupal has a bright future and during the OSCMS conference I was really excited about becoming a part of that but I’ve had to give my head a shake and face the fact that it may the right community for my project but, unfortunately, it is not the right tool for the job. [...]

  • 28 Del.icio.us Links » Blog Archive » links for 2007-09-25 // Sep 25, 2007 at 5:54 am

    [...] archivematica » Drupal as a MVC framework? (tags: to_read) [...]

  • 29 Web Frameworks: Which one to learn first? | Zenning! // Jul 23, 2008 at 5:10 am

    [...] I have been a Drupal developer for over an year now. After working on two projects based on Drupal, one of them being my own site Jhoom and another an upcoming local community-based site, I am now planning to expand my open source development skills further by learning a web framework (’another framework’ if Drupal is considered as a framework too). [...]

  • 30 Web Frameworks: Which one to learn? | Tea Break // Jul 23, 2008 at 9:23 am

    [...] I have been a Drupal developer for over an year now. After working on two projects based on Drupal, one of them being my own site Jhoom and another an upcoming local community-based site, I am now planning to expand my open source development skills further by learning a web framework (’another framework’ if Drupal is considered as a framework too). [...]

  • 31 links for 2008-09-11 « /home/servrrockr // Sep 11, 2008 at 7:00 pm

    [...] Drupal as a MVC framework? (tags: drupal mvc framework) « links for 2008-09-10 [...]

  • 32 365 Capita » Blog Archive » dMVC: a mini MVC framework as a Drupal module // Jan 18, 2009 at 2:37 am

    [...] the early frustration of a long time users of MVC frameworks (Struts, symfony.) There are several discussions about whether Drupal abide by the MVC principles or not. But the consenus seems that Drupal is not [...]