[Imc-drupal-dev] 3rd draft ready

[mark burdett]

Here are some thoughts re: Drupal as a framework.  I don't go around 
recommending Drupal over other frameworks, in fact I prefer to tell 
Drupal horror stories ;) It's just one of many potentially viable 
solutions, and is more or less viable depending on the project and who's 
working on it.

> 	1. The case is very simple. While it's possible that Drupal 
> 	could be adapted to this architecture, ultimately Drupal is not 
> 	a rapid application development framework. It offers modules and 
> 	an API to deal with them, but Drupal is sorely missing all the 
> 	truly amazing things that Cake (as in CakePHP) offers you as a 
> 	programmer. Drupal doesn't want to be a framework, but when you 
> 	boil it all down, Drupal MUST be a framework in order for it to 
> 	be competitive. And it just isn't that nor do the developers 
> 	intend it to be. To me, this is the end of the story.

I read on a blog that CakePHP and Drupal are like "avocados and 
oranges".  CakePHP is a framework, while Drupal is both a CMS and a 
framework.  There's some discussion of this at 
http://drupal.org/node/265726 and http://en.wikipedia.org/wiki/Drupal

Drupal also has a very different architecture from the MVC 
(Model-View-Controller) frameworks like CakePHP, Django, Rails, etc. 
It's been described as having a PAC (Presentation-Abstraction-Control) 
architecture at http://www.garfieldtech.com/blog/mvc-vs-pac

Drupal has a very different style of agile development from the MVC 
frameworks because it already does so much for you.  Developers will 
spend a lot of time altering and extending pre-existing objects and 
workflows rather than building a CMS from the ground up.

Another odd (or empowering, depending on point of view) thing about 
Drupal is that a "developer" can end up using user interfaces provided 
by Panels, Views, CCK, Media Mover, Triggers, Rules, etc. to do a lot of 
what would normally be pure coding.  Although it is possible to code 
this stuff or export code later.

I would say that those who have been using MVC frameworks are going to 
be understandably skeptical of Drupal.  They want to build an optimized 
system from the ground up rather than reusing components, and they don't 
need a UI to configure everything like Drupal provides.

In my own experience of using several frameworks including Symfony, 
Django and Rails, there were various reasons Drupal wasn't used, like 
building something very specialized and Drupal wouldn't save any time at 
all, or other folks working on the project weren't familiar with Drupal.

> 	1. Modules - Drupal modules can be very attractive but can be a 
> 	problem when is not supported for new versions of drupal. 
> 	Collectives who have use drupal since 2002 had many problems 
> 	with that, being forced to keep some sites under old versions 
> 	for a long time, which also make it difficult for those sites to 
> 	benefit of security patches and plugins that only run on new 
> 	versions.

Upgrading sites has been a big headache.  Although, if you minimize the 
custom modules on a site, you can then rely on the commmunity to 
*eventually* upgrade most of the code for you.  My own experience has 
been that it's worth it to put time into upgrading because the new 
versions of Drupal offer tons of improvements for end-users and 
especially developers.

For example when I upgraded a module from Drupal 5 and Views 1 to Drupal 
6 and Views 2, it became a much more powerful module and at the same 
time I was able to reduce it to ~half the amount of code and do a lot of 
refactoring to clean it up.

What I have seen recently is the time between major releases of Drupal 
seems to be slowing down, with core releases getting delayed and then an 
extra wait for modules that your site depends on to be ported (like 
Panels module still being worked on for Drupal 6).  So hopefully, we'll 
see more time between upgrades and also more benefits of upgrading.

Some recent good news about Drupal as a development framework is that 
with Drupal 7 it's finally reaching the 21st century in some areas: 
object-oriented code is slowly making its way in, patch-by-patch, and 
there's a built-in test framework to encourage test-driven development.  

--mark