Drupal开发者应避免硬编码

  硬编码的定义


  硬编码是通过特制代码处理非常特殊情况的方法。这里给出应用于 Drupal的硬编码例子:

  在一个tpl文件中插入SQL查询语句

  编写一个查询数据库的脚本对节点做一些变更

  在一个主体化的函数输出内容中使用正则表达式将一个HTML class属性改为另一个值

  上面的例子可能在某段时间甚至一直有用。然而,如同修改内核,仅仅考虑效率并不足以使之适用于Drupal模式。即使当硬编码有效时 – 虽然它时常不能按预期的方式生效 – 它也在用代码处理通用性的场景上带来了额外的编码成本。

  为什么你应该避免硬编码


  如果这似乎是一个坏主意,那么应该没人愿意硬编码他们的Drupal站点。然而,Drupal.org上有大量提交的修复工作在某种方面是硬编码的。那是因为硬编码对于匆忙的或者刚入门的程序员来说通常是有吸引力的。他们发现了一条节省大量时间的方法,并且对于短期的运行而言,他们是正确的。问题是,硬编码工作会带来隐藏的成本,那将花费大量的时间。

  诸如“不要将代码放入主题层”或者“使用钩子系统”的注释非常普遍,也有表示规范的硬编码警告。然而,对于新的Drupal人来说,很难找到为什么硬编码通常是个坏主意的描述性信息。

  所以这里给出一些使用硬编码带来问题的特定例子:

  你在开发一个主题

  你添加了一条特定的SQL查询语句,用来保存并展现一个用户有多少保存的条目。现在你想在一个不同的drupal安装版本中使用那个主题。如果其他的安装版本有不同的表名,或者使用不同的模块存放用户信息,需要另一种不同数据表连接的顺序,该怎么办?你特定的查询现在毫无用处。

  你设计了一个函数用来缓存并展现用户信息

  这将使得与处理器非常紧耦合,并且您的客户端也要缓存他们的结果。如果你并未按最初的想法利用Drupal缓存机制来工作,会发生什么?

  你需要在站点横幅广告处改变主题

  然而,你用来选择一条随机横幅广告的代码被放入了站点page.tpl文件中。这意味着除非页面在您的函数被调用的地方已经被渲染,否则你不知道什么广告将被显示。要是HTML在此之前发生变化了又会怎样?

  你在站点主题上有五个变量,使用了不同的模板文件

  它们每一个都有一条你手写的查询语句。如果查询需要更改,你需要在六个地方做同样的编辑 – 哎呦,我是说五吗?我一定忘了站点的手机主题是存放在完全不同的文件夹下。你应该不会那样忘事,对吗?

  其他人开始在你的代码上工作

  如果你使用了硬编码的解决方案,即使熟悉Drupal,他们又如何知道发生了什么?记住,这不同于您的个人博客,其他人可能成为项目中的一分子。就算是您的博客,你如何知道你记下了多少一年以来的代码?

  记住,硬编码失败主要在于不能预测到各种因素。从一个页面请求到处理请求的Drupal页面,这个过程需要您的服务器执行上百个函数。采用Drupal自带的钩子,这个过程是正常的并且可预测的,你用就可以了。你能够对那些函数交互的所有方式完全了解吗?如果不能,您选择脱离Drupal框架的行为将给您的站点/您自己/您的宠物带来了不可预期的风险。

  例外


  尽管如上所述,硬编码和修改内核在一个关键点上是不同的:还是有很多合理的场景下需要使用硬编码,并且大部分Drupal开发者不得不时常这样做。有时,你仅仅需要将一堆特殊的用例挑选出来,硬编码是一种有效处理此类问题的方式。例如在一个特殊的节点ID上显示Halloween主题,而这个节点你一年才用一次。用一个模块添加一个表单选项以选择一个主题就显得麻烦了,因为你知道你几乎不会使用它。

   如果你准备硬编码,小心使用,经常咨询一些建议,在你根本不确定是否应该如此的时候;或者如果你确定的时候,因为那样更加危险。