最近陆续用将drupal用到了生产环境，一个企业管理系统和一个互动网站。

又一次增进了对drupal的理解。

仅用drupal实现已个blog的应用时，它看上去就只是一个cms，但是当大量的接触模块时，drupal就是一个提供了ui的框架。

先说点闲话，接触drupal 1年多了，身边很多同事还是在争论cms谁更强大的问题，在我看来，如果涉及到二次开发，cms强不强大完全由开发人员的能力和熟悉程度决定，已经脱离了cms系统本身，例如有人写过如何用wordpress创建一个门户网站，但是内容大量的是PHP的代码，也就是说，除了数据库用了初试安装的部分表、模版引擎，其他全是自己开发的，这已经脱离了cms本身，而是如何把自己的程序代码整合在cms上。因此这些强大的实现能力取决于开发能力而不是cms。

因此在讨论cms的时候，我会尽力的排除开发人员自己开发能力的因素。

在这1年的时间里，从学习到生产，共使用drupal做了3个正式项目和5个测试项目，但从未开发过自定模块和主题，因为目前drupal提供的模块已经完全可以满足我的需要。

目前我对drupal的理解更像是可视化的框架，同时drupal也具备面向对象的特征，与oo语言对比，drupal的模块是可以继承和封装的。

drupal的一些模块很具体，安装后会多出一些配置界面或者生成block 或 page，这些模块就像是一个新的类，提供了全新的属性和方法。

而另一些模块没有具体的配置界面，也不会直接生成block或page，而是扩展其他模块或提供api，这样的模块不能直接使用，而是为其他模块服务的，这更像是一个抽象类或者基类。

因为这些特征，让drupal有了多样性，同样的功能，可以通过安装现成模块实现，也可以通过搭配模块实现。

例如，积分功能，userpoints 模块是现成的模块，它依赖rule、entity reference 等模块，安装启用后，会生成很多rule规则。另一种方法是通过flags模块和rule自己搭配配置出积分功能。

还有例如 answer模块，也同样可以通过创建content type 、设置node_reference 、flags模块来实现。

这样的感觉就像开发时自己封装方法还是用第三方组建，这样的例子在开发中很常见，例如用第三方的ORM或是自己封装数据库处理方法，又或用第三方的上传模块还是自己用php的上传功能。如何选择都是更具自己的能力和对第三方提供的组建的信任度。

durpal与其他cms相比，这种类似对象语言般的多样性，造成了drupal学习曲线的陡峭。

其他的cms，具体的模块提供具体的功能，很容易理解，而drupal需要用面向对象的逻辑去理解，为有的模块安装了什么都没有；为什么实现一个xx功能要安装这么多模块，这么难配置；为什么别人的a模块有一个选项，我的a模块没有；这些问题都是drupal的多样性造成的，drupal提供了一个框架，社区中大量的开发人员开发了许多的模块（对象、类），drupal的用户需要自己组合这些类来实现具体的功能。

从结构和多样性来看，不难理解为什么drupal评价这么高，而学习起来又这么困难，我记得网上有一篇文章说聘请了几个drupal团队的老外也不能解决他们的问题，因而质疑drupal的可控性。其实这个问题很容易想通，就像java语言的开发者并不一定能解决使用java语言的项目的问题。

建议：

大部分的开发人员都会建立数据模型和类试图，以便于协作开发和维护。

而drupal既然同样具备多样性，那么建立内容模型和模块试图会是解决写作开发和维护的好办法。

drupal中的content type由于可以使用entity reference 术语 等非基础类型字段，因此可以看作是关系字段，内容模型中，绘制关系就很有必要了，这样在做试图的关联设置时也会正确很多。

模型试图则是将模块之间的依赖关系和作用通过图形绘制出来，这样在进行模块安装和设置时会很有指导作用，对今后的模块维护也很有用。