今天在写Blog时，发现Blogger的编辑页面中的编辑框实在是太小了。便能过Firebug把其高宽都调了了调，很好用。不过下次再用时，还要用Firebug来调，很麻烦。我记得有一个Firefox的Add-on叫Better Gmail，它是用本地的脚本去定制Gmail的样式，给我了点灵感。我马上就找到了Better Gmail所使用的核心插件——GreaseMonkey。
GreaseMonkey插件主要是可以让浏览器的使用者自定义网站的样式，或执行javaScript脚本。这样，我只需创建一个js脚本（GM是以.user.js为结尾的文件），然后使用GreaseMonkey设置，将进入Blogger的编辑页面时载入，就可以了。我写的脚本如下：
function addGlobalStyle(css) {
var head, style;
head = document.getElementsByTagName('head')[0];
if (!head) { return; }
style = document.createElement('style');
style.type = 'text/css';
style.innerHTML = css;
head.appendChild(style);
}
addGlobalStyle('#richeditorframe { height:500px ! important; } #modebar, #richeditorframe, #richbars, #editarea
{ width: 1000px }');
感兴趣的朋友们可以试一试。
Drupal自带有“论坛”的功能，相信国内的广大Drupal使用者对Drupal自带的这个论坛功能也很感兴趣。但是，质疑声也是此起彼伏。很多开发者认为Drupal的论坛很不适合国人使用，因为其功能较为简单，且操作方式等也不太方便。那么Drupal论坛的特点是什么？究竟在哪种项目中适合使用Drupal的论坛呢？本文将引领大家简要了解Drupal的Froum，分析其适用场景及使用方法，并给出我的看法。
引言
Drupal的Forum模块是核心可选模块，开启Taxnomy和Comment模块后即可以使用。Drupal官方认为这个Forum像phpBB那样的message board。核心功能就是：
这是Drupal论坛的设计宗旨，知道这两点可以便于设计者决策在实际项目中是否采用Drupal论坛。通常的情况下，客户们只说：我要一个论坛。但他究竟要的是什么样的论坛？主要的功能是哪些？这都需要详细的确定才行。比如下面两个客户对论坛的需求是截然不同的：
客户甲：我需要一个简单的供用户交流的地方即可。论坛可以分为几个部分：产品讨论、使用交流和客户服务。嗯....只需要简单的发帖回帖应该就可以了。
客户乙：我们要打造全宇宙最酷最棒的论坛。论坛功能要炫！论坛版块要又多又全，用户互动性和可玩性要强，什么金币啊、等级啊、荣誉啊，一个都不能少！还可以互相买卖帖子，可以发不到一定等级就不能浏览那种帖子。积分功能要全，根据积分等级还要分什么虾米、大侠等，总之就是：炫！另外，由于用户至少同时在线１００万，每个子论坛至少要支持１０个以上的版主......
的确，第二个客户的需求有些夸张，存在的可能性也微乎其微。不过从这两个客户的需求上可以看出，虽然他们要求的都是一个“论坛”，但预期还是很不同的。前者需要的是论坛的基本功能，而后者则需要一个非常完整而复杂的论坛”系统“。那么结合Drupal Forum的特点，我认为，Drupal Forum比较适合前一类客户的需求。也就是说，Drupal Forum比较适合作为一个网站的支持社区，而不是作为主体功能。
当然，我并不是说Drupal的论坛过简，由于Drupal强大的扩展性，我们可以自定义模块来进行论坛功能的增强。不过要在动手之前看看成本是否可以接受，还要考虑性能方面等问题。这也主要通过测试来考量。
Drupal论坛的组织结构
Drupal论坛由Forum和Container组成。前者就是我们熟悉的论坛单元，比如论坛分为“国内讨论”、“国外讨论”等，这些都可以创建为Forum。Forum还可以无限的嵌套，也就是有子论坛。而Container只用于对Forum进行分组和归类，用户不能在Container内发表主题。Container也是可以嵌套的。Drupal以这种方式组织论坛很容易让国人费解，其实只要一种Forum就可以了。 下图为Container和Forum的层次结构图。
我推荐的方式是这样的：最低层的论坛使用Forum,而其上的各种分类都使用Container。这样可以让用户只在最低层的论坛里发主题，就避免了在某个大类的论坛里发主题，好处就是在进行论坛主题归检索和显示时，大大提升检索效率。
为什么使用Drupal论坛
我认为使用Drupal论坛的原因很简单：它可以与其它网站的用户服务紧密的联系在一起，并可以利用Drupal的模块架构来进行功能扩展。Drupal是一个整站的框架，其中可以包含各种内容发布的功能，如博客、相册和论坛。那们，使用Drupal自带的论坛，可以有机的将这些功能整合在一起，给用户提供完整一致的使用体验。另外，对于计算用户贡献（如积分等制度）也是非常方便的。如果单独使用专门的论坛，如phpBB和Discuz等，如果很好的将论坛与Drupal站点相结合，就成为了一个不小的问题。而且由于目前还没有一个统一的标准来实现异构程序之前用户信息的同步，因此，使用Drupal构建的站点要使用论坛的话，最好的方式还是使用Drupal自带的Forum功能。
我曾经尝试过使用Discuz作论坛，来和Drupal集成，不过效果很不好。可能一方面因为我没有掌握Discuz的UCenter，另一方面我觉得UCenter还需要完善其API，使其更好用，而且文档和示例应该更全面一些。
常用的扩展模块
Drupal还是有很多关于Forum的模块的，比如最著名的当属Advanced Forum（简称AF）了。它的主要功能是使Drupal Froum看起来更像Forum，而不是简单的将节点和评论组织起来。比如它会将帖子的样式更改为：左侧是发表者头像和是否在线等信息，右侧为主题帖的内容。不过它的安装稍显复杂，而且目前针对D6还没有稳定的版本。
除此之外，还有一些模块可以起到辅助作用，如User Point模块可以使论坛具有积分系统，User Stat模块可以获取用户的一些注册日期、发帖数量等，用于计算用户等级并定制显示等。
示例
用事实说话，才会使人信服。我看过一些Drupal Forum搭的论坛，感觉不错的确实有几个，比如The Webmaster Forums（http://www.webmaster-forums.net），下面是一些截图，可供参考。
总结
简单的说，喜欢欧美风格的朋友们应该比较适合使用Drupal Forum。不过, 好不好用，还要用户说的算。以上只是我的个人观点，欢迎朋友们和我讨论。
值此新春到来之际，我代表我和我的家人，对在过去的一年来对我给予极大支持的同学们、朋友们，以及广大的Drupal爱好者们致以最诚挚的问候：祝愿大家在新的一年里，万事如意，心想事成！在牛年里，无论是学业、事业还是家庭，都牛气冲天。特别感谢美丽可爱的Ballet网页设计，也祝福Drupal在牛年发展的更好。
有朋友问起关于在Drupal中生成图表的功能，并推荐了一个Charts模块。但经我的试用，发现这个模块文档奇缺，无法简单的安装成功。因此找到了另外一个模块：Open Flash Chart API。
为了方便大家的使用，我将做一个小视频，欢迎收看，敬请关注。
上节回顾上一节的进展为：
- 创建了Food的Content type
- 使用CCK创建了Food的相关字段
- 修改了node-food.tpl.php
目前，简单的菜单管理功能模块可以说基本上完成了，除了权限控制部分。我认为权限控制应该在所有系统功能完成后再统一考虑，目前还是先实现功能为主。那么接下来，就可以进入订餐功能模块的开发了。本文我们就开始订餐功能的设计和开发。
订餐功能模块分析公司员工在浏览了菜单后，可以选择订购此午餐，同时设定购买数量。由于菜单是一个套餐，因此通常一个员工只会选择一种套餐。但是，此处我认为应该在一定程序上考虑系统的可扩展性，也就是说，应该考虑一个用户订两个或多个“套餐”的情况。因为很显然的是，员工小A想替小B和小C订餐的话，那么使用小A的帐户就需要同时订购三种不同的套餐。
其实此处就存在一个实际的业务模型和系统模型间的映射关系。如果只是从“一个员工中午只吃一种套餐”的常识来想，将每个“帐户”设定为“只允许订购一种套餐”的话，做成的系统就明显不适合使用了。这点也提醒做系统设计的朋友们要注意。
由于目前本系统只限于某公司员工内部使用，因此不存在需要填写送餐地址的信息。同时为了方便起见，暂时不考虑网上支付。这样问题就简化了。另外，用户在订餐时，通常会按照个人口味提出一些建议，因此系统还需要提供一个文本框，用于用户对订餐进行一些“补充说明”。
总结一下，订饭的流程如下：
- 浏览菜单并选择“订购”某套餐
- 设置订购数量
- 输入补充信息
- 查看购物车并确认生成订单
- 查看订单状态（已收到订单、已发货、收货确认）
图！图！图！
我认为任何语言的描述都不如页面草图来的直接。UML和简洁的文字都不是和客户交流的最好方式。看得见的页面图才是最有效的办法。
上面几张图演示了在浏览套餐菜单后，可直接订餐的全部过程。
（未完待续）
