Highrise对Rails的意义

最新推荐文章于 2007-12-23 00:00:00 发布

翻译最新推荐文章于 2007-12-23 00:00:00 发布 · 8.5k 阅读

标签

#rails #authentication #工作 #api #tags

本文回顾了Highrise项目的开发历程及对Rails框架产生的重大影响，包括多态结合、预先加载和代表性状态传输等特性的发展。

Highrise马上就要到自己一个月的纪念日了。终于能够把它顺利推出对我而言是很大的解脱，而且能够看到它成为我们销售业绩最成功的产品是很美妙的一种感觉。

我们已经在这个项目上断断续续工作了超过一年了，这个对于37signals而言就等于是永远了。当然了，这其中也包括了6个月以上的暂停和划掉再重来的过程，但是还算很长了。

虽然这个项目本身花了很长时间来完成，但是大部分Rails开发者已经从中获益良多。一套备受瞩目的Rails特性都是在我开发Highrise的过程中被总结出来融入Rails的。这里有三个大的突出特性：

多态结合 （Polymorphic Association ）

为了能标记人和公司（未来还要能标记案例和笔记），我已经想到了一个办法来导向另外一个结合以将其作为一个角色。简单的说，多态目标。所以在Highrise里面，标签被链接到“可以被标记的项目“。在多态结合以前，传统的Rails的想法都是通过一个标签对应一个集中表格的结合方式来实现的。所以就会有这样的标签：companies_tags, people_tags,等等。恶心。

尝试性的实现这个功能的代码最开始被作为一个“ 当作可以被标记“的插件来处理，但是我们后来在Highrise里面放弃使用了。因为在我们简化了标签化以后，认识到多态结合让这个实现变的微不足道，所以也就不值得花时间和精力来抽象化这个功能。

预先加载 (Eager Loading)

Highrise的第一版的授权系统复杂的可怕，也因此造成了无数关于主要记事页面的问题。最早期的benchmark测试是我不得不试着采用预先加载来试图绕过这些问题的原因。

最后证明了这是一条死路 (系统仍然是一团糟)，所以我们就把我们一开始设计好的极度灵活的设置划掉重来，采用了简单得多的设置。预先加载不再是必需的了，但是不管怎么说也算是对浪费时间的一个安慰奖。

和代表性状态传输的无缝融合 (RESTful Loving)

从第一天开始，我就想要Highrise自带一个API (生成了AR#to_xml), 和RSS提要完全接轨（生成了resource_feeder这个插件），而且能和CSV （Comma-Separated Values）进行交流。自从我花了太多时间在把这些功能加入 Basecamp以后，我再也不想把这些功能作为需要花很多时间对付的东西。既不是在服务器端，也不是在客户端（这个意向引出了动态资源（Active Resource）的诞生）。

所以我们一开始就认定要把这个应用本身当作一个API.这个想法迅速和HTTP全面密切接轨，而且很大程度上保证了REST（Representational State Transfer 代表性状态传输）会真正在现实环境中开花结果。

具有讽刺意义的是，Highrise推出的时候一个记录在案的API都没有，但是在我彻底修改和润色技术文档以后，API会被加入进来。

小细节

虽然上面的三个大的特性和主题很容易就能被指出，我其实更加满意我所做的一些小事。当我回头看修改日志的时候，我能看到细小的微调，精妙的润色，而且我能几乎把所有这些提交回溯到Highrise里用到这些变化的相关录入。

把我们现有的东西变的更好，更简单和更漂亮是完完全全的享受。也是在很强烈的提醒着我为什么仍然热爱在Rails上工作。即使是在这么多年以后。几乎没有一个值得工作的日子，我没有找到可以改进的地方。

简单的有帮助，OpenID 和动态资源

Highrise继续着扮演着推动我个人改进Rails的角色。简单的有帮助的格言（Rails 2.0的主题之一），让Rails和OpenID非常简易的混合使用这个使命（现在正在进行 open_id_authentication插件的实验），让动态资源推出1.0版的推动。我努力的工作着，因为我需要。

原文链接： http://www.loudthinking.com/arc/000607.html