This'll be a fun discussion :-) I see MVC in many aspects of Drupal, though none are pure implementations according to the Go4 and Smalltalk/Java purists. Our controller is a combination of the menu system and the hook system. The menu system is responsible for all Drupal paths, and the paths are what determines which functions get called (via the hook system). Our model is mapped pretty much directly to the relational database structure. Our main object types are Node, User, Comment with other types playing supporting roles. The view is the theme system, of course. What is interesting about MVC discussions in the context of webapps and Drupal is that it is really a bit out of place. The pattern is really the most at home in GUI design for graphical applications where widgets on the screen know how to render themselves based on well defined state information that is given to them by the controller (guess these could be our theme funtions). The widgets communicate a user's actions to the controller, which can cause state changes in the model, and the controller communicates model state changes to the widgets. If you look at it, it is very difficult to write a pure MVC pattern for a web application, and it is almost as difficult to *not* write some sort of MVC pattern for the same. Since becoming involved with Drupal I've commented several times that I'm glad we *don't* dwell on MVC. It was such a fad in the late '90s. It's not that I'm against patterns; on the contrary, they are essential to understanding software and any time I learn a new pattern I become a better programmer. I just think that calling something MVC doesn't make it inherently better (bike != mercedes, no matter what Bèr will tell you ;-)) -Robert Kieran Lal wrote:

Here's a quick overview of Model View Controller architectures that was updated in April 2005. http://www.jdl.co.uk/briefings/MVC.pdf

I haven't spent a lot of time thinking about this. 1) Modules represent the model. They are unaware of the view, theme. 2) View - To me there are three stock views, or outputs, in Drupal. The first is just themeless output. The second is the themed output. The third is as an XML-RPC request. 3) Controller-this is traditionally about controlling input. The controller knows about it's views.

The question is, does Drupal have a controller, and if it does, is it the Forms API. This is a question that is consistently coming up in comparing Drupal to Ruby On Rails and I'd like to have a solid answer.

Cheers, Kieran

On Monday 26 September 2005 08:09, Kieran Lal wrote:

2) View - To me there are three stock views, or outputs, in Drupal.   The first is just themeless output.  The second is the themed   output.  The third is as an XML-RPC request.

Here lies a task for us too. Drupal has the themes for view, but ATM the only output possible is HTML. That is (and there lies a huge taks) because of a lot of hardcoded HTML. So in order to get the V layer correct, we need to get all the hardcoded HTML (even if they are hardcoded in theme functions) away, or better centralised. One possibility is a theme wrapper function: a lower level function that will allow you to define, in one place, what HTML/PScode/SVG etc is used to wrap your content in. Ber