Drupal,xoops,joomla!评测
Saturday, 21. October 2006, 02:12:24
先声明这篇文章仅从我的需要方面来比较Drupal和Xoops，其实到现在为止，我仍然在心里没有一个定论，是用drupal还是xoops来构建公司的内网门户，写下这些东西，只是为自己作出选择提供一些依据，无法这次选定是影响深远的，因为一旦选定，那么以后开发的所有功能都可能针对与它们之间的一个来开发模块。我考虑的几个方面如下：
除了它们本身都是很优秀的CMS系统之外，我看上它们几个的一个原因是因为它们都有gallery的模块，而gallery我非常的喜欢；而blog系统我之前考虑的是LifeType，因为以前我在Plog（LifeType的前身）上做过二次开发，所以比较熟悉那些代码；但是这个是否容易集成，也在我的考虑范围之内。甚至前两天的工作都是研究关于SSO的东西，我想找到一个优雅的解决方案，让各个我选定的优秀的开源系统可以协同工作。
其实我是优先考虑的drupal，因为它的个头稍微小点，它的代码也很优美，无论是从内容还是格式上，它的那个给予LIMIT和OFFSET的分页处理很巧妙；他的代码缩进风格我很喜欢，那是Java的编程风格；它的技术实现比较独特，我是从三个方面考察的，模板引擎（原始的php），插件和模块的处理(实现drupal系统hook的各个方法)，国际化和本地化（类似于gettext）；但是装了之后，界面是很清爽的，并且操作提示（成功或者失败）很友好，这个对比于xoops来讲，我个人很不喜欢xoops每一个操作都要reload。然而使用drupal给我的使用感觉是有点迷糊，Drupal可能更合适高级用户使用，说真的，如果是用Drupal做一个企业的外部网站，用于展示产品等等的，更新不是特别频繁，管理员少，可是作为一个企业的内网门户来讲，用Drupal可能不太合适（保留意见，待有时间进一步研究），它的论坛，博客等等和Drupal本身联系得太紧密，风格等等都一样，这样我想比较容易让人混淆，而且后台界面也同样比较适合于博客用户，如果我分配一个权限给某个部门添加企业的新闻什么的，那么那个界面我想是不太能让人接受的，据说有插件可以做这个工作，但是我想Drupal还是比较合适于blog站点，社区站点，某个项目的站点，我最早开始知道drupal也是因为linuxsir用它。另外说一句drupal的代码很值得一读。
接下来考察xoops，想选择xoops的理由：
昨天晚上好好使用了一下，并且通读了它的部分源代码之后，有几点是我不太满意的，还是针对于我的需求。相对于Drupal，它可能更加合适做公司和企业的门户，无论是内网和是外网门户，这像它宣传的一样。然而我不是很喜欢它的管理界面，这个集中在可用性，用户友好性，美观程度上，与功能没有丝毫的关系。它的定制功能已经很精细了，几乎涵盖了一个CMS该有的各个方面，所以我说在功能方面我无刺可挑。然而，没一个操作总是要reload一个页面，这不是很友好，其实我想如果把这样的提示信息放到后台管理界面的最上面（通常放banner的区域）或者在主要内容的最上面（针对于左右两栏的通常布局，左边是菜单栏）可能会更好一点；另外出错之后只是单单给出一个提示信息，而不在下面加上返回或者手动或延时默认跳转页面的机制，这很难受。管理菜单以及各个模块的管理菜单在模块安装之后自动出现在左栏，这是很好的，也是我之前比较赞同的。最后说美观程度，其实它的界面是很简单和明了的，我自己平常的程序的管理界面基本也做成那个样子，因为手写html代码，不会有太多的修饰，所以只是在各个div上留下id，以便于下一步美化的时候css可以用。可是我通常只是留着，而没有进一步的行动了，后台嘛，别人又看不到。然而我始终这样认为，在功能不打折的情况之下，应该越漂亮越好。
现在另外一个优秀的程序Joomla！出现在我的视野，它真的很漂亮，还没有看它的代码，但是界面实在是非常的吸引我，这体现在用户友好性，美观性方面，这些是我对比于xoops来说，而且它也是今年开源CMS大赛的5强之一。了解它的历史是在mambo的基础上开发的，而mambo之前的商业包装得很好，也许是这个原因，传承了界面友好方面优点（不确定，因为没有用过mambo）。写到这里，我其实很想写另外一篇文章，关于web程序界面的可用性，用户友好性方面的东西，这些我感受很多，也想了很多，可以一直以来我没有时间或者说没有机会和压力去做得更好。一个很简单的东西，点击“确定”按钮之后，应该让这个按钮disable了，避免用户由于等待而重复提交表单，但是就算是这点，我也注意得不够，也许在实际的应用中也很少遇到网速慢要求苛刻的情况，又或者是不专业的开发工作没有客户苛刻的要求，亦或者有组件可用了，比如struts的html taglib。
昨天晚上看xoops的代码看到两点，只想这两天加班的时候把方案确定好了，周一就能快速的进行工作了，也许我现在最首要考虑的是应用它们达到我的目的所花的时间最少，实际上就是二次开发的难易，包括界面的翻译（Joomla！的简体中文语言文件好像还没有），插件的体系结构和开发速度，这要看过部分源代码才可以知道。
To be continue...
- 二次开发的难易，以及和其他系统集成的难易
- 界面，无论是前台还是后台管理的界面
- 是否有我需要的功能的插件，我需要博客，相册。
- 支持LDAP的验证方式，这个便于和公司里的其他系统集成
除了它们本身都是很优秀的CMS系统之外，我看上它们几个的一个原因是因为它们都有gallery的模块，而gallery我非常的喜欢；而blog系统我之前考虑的是LifeType，因为以前我在Plog（LifeType的前身）上做过二次开发，所以比较熟悉那些代码；但是这个是否容易集成，也在我的考虑范围之内。甚至前两天的工作都是研究关于SSO的东西，我想找到一个优雅的解决方案，让各个我选定的优秀的开源系统可以协同工作。
其实我是优先考虑的drupal，因为它的个头稍微小点，它的代码也很优美，无论是从内容还是格式上，它的那个给予LIMIT和OFFSET的分页处理很巧妙；他的代码缩进风格我很喜欢，那是Java的编程风格；它的技术实现比较独特，我是从三个方面考察的，模板引擎（原始的php），插件和模块的处理(实现drupal系统hook的各个方法)，国际化和本地化（类似于gettext）；但是装了之后，界面是很清爽的，并且操作提示（成功或者失败）很友好，这个对比于xoops来讲，我个人很不喜欢xoops每一个操作都要reload。然而使用drupal给我的使用感觉是有点迷糊，Drupal可能更合适高级用户使用，说真的，如果是用Drupal做一个企业的外部网站，用于展示产品等等的，更新不是特别频繁，管理员少，可是作为一个企业的内网门户来讲，用Drupal可能不太合适（保留意见，待有时间进一步研究），它的论坛，博客等等和Drupal本身联系得太紧密，风格等等都一样，这样我想比较容易让人混淆，而且后台界面也同样比较适合于博客用户，如果我分配一个权限给某个部门添加企业的新闻什么的，那么那个界面我想是不太能让人接受的，据说有插件可以做这个工作，但是我想Drupal还是比较合适于blog站点，社区站点，某个项目的站点，我最早开始知道drupal也是因为linuxsir用它。另外说一句drupal的代码很值得一读。
接下来考察xoops，想选择xoops的理由：
- 采用smarty模板引擎，这个我比较熟悉，开发起来够快。
- 更感觉它做的是一个集成工作，可以把那些模块如此巧妙的放在一起工作，即使只是定义了一种集成的标准也已经足够
昨天晚上好好使用了一下，并且通读了它的部分源代码之后，有几点是我不太满意的，还是针对于我的需求。相对于Drupal，它可能更加合适做公司和企业的门户，无论是内网和是外网门户，这像它宣传的一样。然而我不是很喜欢它的管理界面，这个集中在可用性，用户友好性，美观程度上，与功能没有丝毫的关系。它的定制功能已经很精细了，几乎涵盖了一个CMS该有的各个方面，所以我说在功能方面我无刺可挑。然而，没一个操作总是要reload一个页面，这不是很友好，其实我想如果把这样的提示信息放到后台管理界面的最上面（通常放banner的区域）或者在主要内容的最上面（针对于左右两栏的通常布局，左边是菜单栏）可能会更好一点；另外出错之后只是单单给出一个提示信息，而不在下面加上返回或者手动或延时默认跳转页面的机制，这很难受。管理菜单以及各个模块的管理菜单在模块安装之后自动出现在左栏，这是很好的，也是我之前比较赞同的。最后说美观程度，其实它的界面是很简单和明了的，我自己平常的程序的管理界面基本也做成那个样子，因为手写html代码，不会有太多的修饰，所以只是在各个div上留下id，以便于下一步美化的时候css可以用。可是我通常只是留着，而没有进一步的行动了，后台嘛，别人又看不到。然而我始终这样认为，在功能不打折的情况之下，应该越漂亮越好。
现在另外一个优秀的程序Joomla！出现在我的视野，它真的很漂亮，还没有看它的代码，但是界面实在是非常的吸引我，这体现在用户友好性，美观性方面，这些是我对比于xoops来说，而且它也是今年开源CMS大赛的5强之一。了解它的历史是在mambo的基础上开发的，而mambo之前的商业包装得很好，也许是这个原因，传承了界面友好方面优点（不确定，因为没有用过mambo）。写到这里，我其实很想写另外一篇文章，关于web程序界面的可用性，用户友好性方面的东西，这些我感受很多，也想了很多，可以一直以来我没有时间或者说没有机会和压力去做得更好。一个很简单的东西，点击“确定”按钮之后，应该让这个按钮disable了，避免用户由于等待而重复提交表单，但是就算是这点，我也注意得不够，也许在实际的应用中也很少遇到网速慢要求苛刻的情况，又或者是不专业的开发工作没有客户苛刻的要求，亦或者有组件可用了，比如struts的html taglib。
昨天晚上看xoops的代码看到两点，只想这两天加班的时候把方案确定好了，周一就能快速的进行工作了，也许我现在最首要考虑的是应用它们达到我的目的所花的时间最少，实际上就是二次开发的难易，包括界面的翻译（Joomla！的简体中文语言文件好像还没有），插件的体系结构和开发速度，这要看过部分源代码才可以知道。
To be continue...
WIDGETIZE