3个技巧让你的features更加易用

搞开发的亲们，要是你遵循了下面介绍的简单指引，你的Drupal Features对于像斯坦福一样的情况来说，将会更加实用。借此你将赢得朋友和要人的青睐。你将挖掘更多Drupal的潜力，和其中蕴含的乐趣。

1. 精简Features，降低耦合性

对于斯坦福这样的地方来说，不同的团队在维护大量的Drupal站点的运行，为了达到提高重用水平的目的，需要建立一种分发的规范。对于Features来说，小的就是好的。内容类型是一种原子Feature，如果没有特殊的需求，我们应该让每个Feature里面仅包含一种内容类型，拒绝不必要的任何东西进入Features。任何其他需要加入的东西，Views/Rules/Feeds/Services之类，都应该在内容类型Features之外，这些“额外”的东西，将依赖于内容类型的Featurs工作。为了保障内容类型Features的独立性，这一类Features不应该依赖其他的Features[注1]。使用<前缀>_base 这样的命名来设置站点的杂项属性（例如图像格式和变量等），其他的Features都依赖于这一Feature，这应该是很符合开发者习惯的做法。但在笔者看来，a) 别这么做； b) 如果已经做了，就纠正吧。

2. 合理利用前缀

前缀是一个常见的利于复用的属性，我在techcommons建立并实施了一个关于前缀的草案，学校的每个部门一段时间里只会有一个前缀。这需要稍稍注意一下，不过并不难。下面是一些已经定下的前缀，如果你有一些在这些组织范围内的小项目，请不要注册新前缀，沿用组织前缀就可以了。

• gsb_(商学院)
• soe_(工学院)
• earth_ (地球科学系)
• dor_ (研究室主任)
• stanford_ (斯坦福Web Service)

点击查看完整列表

3. 命名空间

值得高兴的是，不少用户已经开始使用KIT兼容Features（这东西很好，Kit），推荐读者阅读一下Kit Features规范。我们也对Kit做了一些扩展工作。一个突出问题就是字段名冲突，以及其他会导致一个Feature无法成功部署到其他Drupal站点的问题。和Drupal中的其他内容一样，我们用前缀来解决这些问题。

需要前缀的场合

• 模块和函数
• 内容类型的机读名称
• Views的机读名称
• 字段
• 所有其他可能的东西

举例

坎特艺术中心正在为一场展览建立一个Feature。他们知道前缀很重要，他们不想和艺术系和艺术史系的其他项目产生冲突，所以，他们使用了Cantor_作为前缀，来管理所有的属性，并将这一前缀注册到了tech commons的页面，广而告之。

内容类型: *cantor_exhibition*
字段: *field_cantor_exibition_image*
View: *view_cantor_exhibition_gallery*

你可能注意到，我们使用了匈牙利命名法来制作这些机读名称，借以表明这一名称所指代的事物。不过对字段来说就有点难度了，字段名称有32字符的长度限制，而且Drupal还用’field_‘前缀占用了其中六个位置。不过如果能够坚持这一做法，我们制作的Features就会有足够的独立性，随着时间的推移，Feartures的逐步积累，更多的使用，将会造就一系列的高复用Features，

如果我们不从我们的大量项目中搜集重复的简单内容类型，那么我们的Drupal建站过程很可能就会迷失在重复劳动中。所以再次重申：Drupal是一个神奇的内容建模框架，内容类型包含了大量重要信息，这些信息对特定领域或用户群是很有分享价值的。我们的目标不是建立一个正式的高端的用例，而是数百个。内容类型一个具有高度相关性和清晰的基础元件，我们可以以此为基础进行学习，继承或开发。我们正在寻找开发团队，同我们一起努力。

请联系我

热烈欢迎任何想要直接联系我，同我探讨关于Features的最佳实践的的开发团队。在开始建立第一个内容类型之前的内容分析建模阶段，是进行这一工作的最佳时机。目前已经有一个团队在进行上述工作（万分感谢），能找到一个造福于所有用户的切入点，足够激动人心。

注1: 这里有一个明显的例外，一个内容类型，包含了另外一个内容类型的实体引用的情况。依赖并不是坏事，我们只是尝试减少不必要的依赖。