[drupal-devel] Does the Forms API give Drupal a model view controller architecture
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
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 Sep 26, 2005, at 12:26 AM, Robert Douglass wrote:
I just think that calling something MVC doesn't make it inherently better
Right. But the why Drupal isn't Object Oriented is a really useful document. We might want to have a MVC one handy when technical decision makers start looking to get answers. An abstract discussion about MVC isn't what I am looking for. A MVC comparison between Drupal and Ruby on Rails is. Cheers, Kieran
Be careful what you ask for ;-) If too many of us start looking too closely at RoR, we might end up with fewer Drupal developers. -Robert Kieran Lal wrote:
A MVC comparison between Drupal and Ruby on Rails is.
On Mon, Sep 26, 2005 at 12:13:25AM -0700, Kieran Lal wrote:
On Sep 26, 2005, at 12:26 AM, Robert Douglass wrote:
I just think that calling something MVC doesn't make it inherently better
Right. But the why Drupal isn't Object Oriented is a really useful document. We might want to have a MVC one handy when technical decision makers start looking to get answers.
An abstract discussion about MVC isn't what I am looking for. A MVC comparison between Drupal and Ruby on Rails is.
I spent a couple weeks experimenting with Rails a few months ago. I won't write a comparison now since Rails has probably changed a bit since I last used it. To summarize: Drupal and Rails are each good for different types of webapps and different development styles. Sometimes Drupal will be the right tool, sometimes Rails will be it, other times neither is good. Right now the main concrete advantage of Drupal is that it runs everyhwere. I expect Ruby will catch up. -Neil
To summarize: Drupal and Rails are each good for different types of webapps and different development styles. Sometimes Drupal will be the right tool, sometimes Rails will be it, other times neither is good.
I think they are very different tools. With Drupal you have a product ready to use, which does certain things. With Rails, you have a set of tools (great tools) to start building a certain thing. With Drupal you can have a site up and running in 5 minutes; with Rails you have to build your site from scratch (although building it its fast). So that leaves apart from Rails many people who hasn't the time or the knowledge. Expect to see a Drupal-like built in RoR in the future. The phylosophy of Rails (or its creator) is to build the framework, but never offer a general-purpose solution for certain problems, because every implementation is different and reusable components are a myth; ie, you will never see a poll module or a blog module built in Rails. álvaro
Robert Douglas wrote:
If you look at it, it is very difficult to write a pure MVC pattern for a web application...
Yes, but not if you're *using* an existing MVC framework like Jakarta Struts. <bash> However, the Java camp is always so keen on writing frameworks but so weak on usable components and real features -- just look at JBoss Portal, for example. Tons of potential, zero features -- try finding a shoutbox or a decent forum component for it. </bash> I'll take Drupal's transparency and "pseudo" MVC design over a huge cumbersome framework any day.
I completely agree, Gravy. I like your moniker, too. GravyFace wrote:
Robert Douglas wrote:
If you look at it, it is very difficult to write a pure MVC pattern for a web application...
Yes, but not if you're *using* an existing MVC framework like Jakarta Struts. <bash> However, the Java camp is always so keen on writing frameworks but so weak on usable components and real features -- just look at JBoss Portal, for example. Tons of potential, zero features -- try finding a shoutbox or a decent forum component for it. </bash> I'll take Drupal's transparency and "pseudo" MVC design over a huge cumbersome framework any day.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It doesn't yet But it will. some time in the future. Probably in another 2 major versions ( or another year, if you think about it that way) , with CCK properly in core, and stuff like the form api and relationship api properly integrated. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDN7PGgegMqdGlkasRAn+eAJ0Xj64sjFlFCeDJCHdsBJjK0IleGgCdFHxO eBgSDnHTDW9BZJCvKI82QE0= =UKck -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26 Sep 2005, at 1:03 PM, Bèr Kessels wrote:
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.
One of my personal goals is to have the first SVG theme for Drupal, and possibly even any OSS CMS (that could be a fun marketing opportunity =P ) I'd also love to do an XUL one, but time.. she is not on my side. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDN+QdgegMqdGlkasRAnYBAKCCFuuY98CQHHlJOGI1zPWo+b5bwACeOZMJ Stj9TwGI1H2ERG83NjYTa1o= =PJJU -----END PGP SIGNATURE-----
participants (7)
-
Adrian Rossouw -
Bèr Kessels -
GravyFace -
Kieran Lal -
neil@civicspacelabs.org -
Robert Douglass -
Álvaro Ortiz