joomla与drupal内核差异分析
不能否认，程序之间的互补很重要，一个程序要完成所有相关程序编写的话，代码量会相当多，而且不能被复用。例如joomla的一个组件已经有缩略图功能了，但另一个组件需要缩略图功能，还要自己再做一个。程序不能互补，就难以技术积累，就更别说能积累出更强大的组件。而joomla中很强大的组件，都必须有非常有实力的团队在支持。 例如Kunena。不得不说Kunena强大，其结构可以比得上一个joomla，而且对joomla各个版本都有支持，也支持很多用户管理组件。Kunena能做出来可以说相当不容易，Kunena的团队必定是非常有实力的团队，一般的开发团队是难以比较的。
也许因为joomla程序的独立模式问题，所以joomla第三方扩展都比较有英雄主义，有不少很庞大也很强大的组件出现在joomla的组件列表中，而且那些组件功能都相当完善可谓是“大而全”。要是搞论坛的话，一个Kunena就够用了。而drupal因为交互性很好，模块要做得“大而全”就没多少意义，所以很少出现“大而全”的模块，一般都需要与其他模块结合使用。
这一切就看似windows和linux，我们不妨把drupal看成是linux，把joomla看成是windows。linux上很多软件都存在依赖关系，但单个软件的体积又很小，这和drupal的module很相似。而windows的软件安装起来很方便，总是有很友好的UI，但体积有时却大得惊人（例如VS.NET的体积，我总是想不通这个IDE为什么这么庞大，而且还必须安装一大堆组件，让我的程序列表总是很长）。
约定优于配置
读过了有关rails的资料，才知道“约定优于配置”是什么意思。而rails是因为这一设计原则，使得开发流程更简易。drupal正是以“约定优于配置”的原则设计，所以开发体验上drupal比joomla更简便。
说说一些开发例子，joomla的组件中总会存在views、model、controller、table等文件，这些文件都有意义：controller是个入口；views决定模板；model把数据整理好提供给views，table决定数据原型。这是很标准的MVC结构，当然也是相当优雅的结构。但经过大量的开发后，你会觉得一些操作很烦琐，例如你的组件数据结构并不复杂，但还是得写model。又或者数据总是读不出来，查了很久才知道model没有按规则去建立。（说实话，我每次开发一个新组件，都是从另一个组件抄代码，不然隔段时间没搞joomla都不知道从何开始）。
而drupal就没有这方面的烦恼，你只需要知道“约定”，那就是系统会自动识别的命名规则。例如drupal关于文章模板的文件名为node.tpl.php，而如果你只想对ID=1的文章用不同的模板，你只需要新建一个node-1.tpl.php的文件就可以了，模板以外的其他额外代码都不用写（同样的功能在joomla上实现还是很麻烦的）。又例如你知道hook_cron这个钩子是用于cronjob行为，你想在你的模块里实现定时清除过期数据，你只需要建一个function命为yourmodule_cron，然后写你的清除代码。
最后
本文的结论是基于drupal6与joomla1.5的比较，两个系统还在快速升级中，所以这种局面不一定会维持现状，也许joomla2.5会给我们带来更良好的开发体验，而这两个都是很优秀的CMS系统。在我的经验中，drupal更适大型企业，joomla更适合中小型企业。而选择drupal的客户，有可能已经拥有运维相关的部门。
