知道什么时候使用过滤器

如果可以使用已有的钩子来处理文本，那么你可能会想，为什么此时还需要使用过滤器呢？例如，使用hook_nodeapi()为URL添加超链接，这也非常方便，比URL过滤器还好用。但是考虑一下这种情况----你需要为节点的主体字段使用5个不同的过滤器。现在假定你查看默认的http://example.com/?q=node页面，它一次显示10个节点。那么算一下，现在为了显示这个页面，你就需要运行50个过滤器，而对文本的过滤操作是很费资源的。这同时也意味着无论什么时候调用一个节点，即便是正被过滤的文本未被修改，那么也需要运行这些过滤操作。你在一次又一次的没有必要的运行这一操作。

    过滤器系统有一个缓存层，极大的提升了性能。一旦为给定的文本片段运行完了所有的过滤器，该文本的过滤版本将被存储在cache_filter表中，在文本被再次修改前缓存的内容保持不变（使用过滤内容的MD5哈希值来判断是否被修改）。现在让我们回到前面的例子中，当文本未被修改时，我们就可以绕过过滤器直接从缓存表中加载10个节点的数据了---速度快多了！图11-7给出了过滤器系统处理流程的概览。

 

图11-7 文本过滤系统的生命周期

 

 

     现在你应该比刚才更聪明一点了，你可能会想，“好吧，如果在我们的nodeapi钩子中直接将过滤后的文本保存到node表中,那不更好吗？它的运行结果和过滤器系统可是一样的啊？” 尽管这一方法也解决了性能问题，但是你破坏了Drupal架构的一个基本原则：永不修改用户的原始数据。假定你的一个初级用户回过头来想编辑一篇文章时，当他看到很多内容都被包含在了HTML标签中时，我想他十有八九会向你打电话寻求支持的。过滤器系统的目标就是保持原始数据不变，同时可以在Drupal框架其余部分中使用过滤数据的缓存拷贝。这一原理应用在Drupal的各个API中，你将会经常看到。