评 《Flexible Rails》

 

"人们选择某样东西，往往不是因为它是最好的，而是因为它是最适合自己的。",我觉得这话也非常适合用来描述 web 开发领域前后台的两个最时尚和最前卫的框架“Rails” 和 "Flex"。

 

如果我说 Rails 是最先进的 web 开发框架，相信肯定会有很多人跳出来反对。我身边就有不少朋友觉得 django 框架要比 rails 好，很多 php 的开发人员坚持用 Zend 来开发网站，这里就更不用提那些使用 java 框架的程序员了，他们不喜欢 rails 的原因可能仅仅是因为“它不是用 java 写的”。其实在这个“物以类聚，人以群分”的世界里，我们必须面对这样的现实，有人喜欢，就一定会有人反对。不过我觉得即便是那些最讨厌 rails 的人也不得不承认这点： rails 在引领 web 开发潮流这一点上可说是一直走在所有 web 框架的前面，甚至有人称它领先别的框架至少两年。 当 Zend 开发组还在讨论是否应该引入 ORM 的时候， ActiveRecord 从 Rails 刚刚诞生的那一刻就是内置在框架中的，而且使用了很多年且不断地在发展； 当 Django 开发组还在讨论是否应该引入包含 ajax 功能的javascript库的时候，Rails 已经将 prototype 集成，并发展出自己独具特色的 rjs template 技术，使得程序员可以用 ruby 语法来开发 ajax 功能； 当 REST 对其它框架还是一种 buzz word 的时候， Rails 已经开始将其全面付诸实现在框架中；当其它框架还在使用 cvs 的作为项目的版本控制系统时， rails 项目组却抛下 subversion 全面采用 git 作为自己的版本控制系统；当其它 web 开发系统还苦于没有自己的功能扩展系统的时候， rails 的 plugin 机制已经为其带来了无数令人欣喜的第三方插件，它几乎包含了你能想到的任何方面的扩展。当然 rails 的缺点也是很明显的，因为它每半年一大的版本升级的更新速度，就算是对那些非常追求新技术的程序员来说，也有一种疲于奔命的感觉。很多人觉得即使只采用不需要任何框架的 php 也照样可以制作全功能的网站，但是 IT 并非机械制作业，这是个非常需要“与时俱进”的行业，所以 rails 受到全世界程序员的追捧也是有它的原因的。Rails 过分灵活动态也是阻碍程序员采用它的一个原因，我想部分原因应该归结于 Ruby，对于那些喜欢简洁语法的程序员来说， python 更适合他们。而隐藏在这背后的其实是两种语言哲学上的不同，python 推崇“一件事情只有一种解决方法”，而 Ruby 则是“一件事情往往有多种解决之道”。从初看一下似乎 python 的哲学理念更正确一些，因为大道至简，但是即便 Guido 如此来设计 python ，他无法阻止人们以各种方式来使用它，python 的框架一点也不比 rails 少。现实生活的事实是“一件事情往往有多种解决之道”，之所以如此，是因为人们在处理一件事情的时候思考的角度不一样，习惯不同，采用的方法也就不同。ruby 的 for 循环实现方法有十多种，并非孰优孰劣，而是每个人来自不同的编程环境，有人习惯 for each 的方式，有人喜欢 iterator，给人们提供不同的选择，让选择权在每个人手中，我觉得这是非常合适的做法，这就是“没有最好的，只有最合适”的最好体现。

 

Flex 同样是一个非常前卫的表现层框架，我曾经觉得如果不是 ajax 的及时出现，可能 flex 的繁荣会早一些到来，但现在看来，就算没有 ajax，照样会有一种非浏览器插件的基于w3c标准的技术替代它出现的。基于 flash 技术的 flex 框架并非十全十美，首先隔在 web 开发人员面前的就是Flash 的 SEO 问题, 当然这个问题正在解决，另外人们对传统技术的依赖和对新框架的观望，学习曲线等的原因，注定 flex 不会很快被采用。随着 html 标准的发展, javascript 框架越来越强大，注定在 web 表现层上混合 ajax 和 flash 的应用将会成为主流。flex 可以说是 adobe 公司为了解决如何让程序员使用 flash 的第二次尝试。Flash 到现在为止一直是以时间线动画为主要创作方式的工具，虽然内置的 actionscript 不断地在发展，发展到3.0 版本后的 ActionScript 无论从哪个方面来说都非常像 java 了，但是 Flash 的操作方式一直是阻挡程序员使用它的一个主要原因，Timeline 这种动画制作的概念对程序员来说还是比较难理解，后来Adobe 在 Flash 中采用了一种基于卡片的 Screen 方式（有些类似 VB 的 Form ）来吸引程序员使用 Flash，但是收效甚微，动画人员不喜欢它，程序员也不学它，于是才有了第二次努力的结果： Flex 出现了。Flex 采用 xml 来描述页面，采用 AS 来实现功能的做法，使得它非常像 JSP 和 Java，尤其是 Flex builder 是基于 Eclipse 的，对于那些熟悉它的 java 程序员来说，简直就是轻车熟路，所以 flex 迅速得到了程序员的认可。

 

Flex 和 Rails 大发展好像都在08年，我是从06年做“乐道”网站的时候开始接触 Rails 的，当时乐道的音乐播放器还是用 Flash 开发的。在07 年底的时候 Adobe 推出了一个叫做 Apollo 的东西吸引了我，我研究了一下开发了一个叫做“乐宝”的小程序，这个 apollo 就是 air 的前身，因为这个东西当时不是太成熟，以至于到了 apollo 发布 beta2 的时候原来的应用竟然无法运行了，所以我就将这个技术暂时搁置起来. 当 08 年 adobe 推出了 air 1.0 后我重新拾起了开发“乐宝”（“乐道”桌面客户端）的计划，“乐道”网 FLash 播放器改版和“乐宝”的开发，以及后来为“饭否”开发“汤匙”客户端，为 javaeye 开发 Jarjar 客户端的，随着开发的深入，我越发体会到 flex 开发所带来的方便性。很多人觉得 flex 做出来的东西比纯 js 动态网页要酷，但这并不是 flex 的优势。我个人觉得 flex 对比基于 javascript 的 ajax 开发的优势在于其组件开发方式，无论 prototype, jquery 多么方便，它提供还只是函数对象库这种代码重用方式，而 flex 基于组件的扩展方式更具备优势，我自己在开发的过程中也大量地使用自定义组件，虽然 flex 提供了 mxml 和 as 两种方式来自定义组件，我个人更喜欢后者纯代码的方式，这种方式更便于打包和共享。

 

如果你在接触了 flex 和 rails 两个框架后，你会很自然地将其联系在一起做应用。以我为例，最初接触 Rails 的时候，我就觉得 builder template 是我见过的最容易的一种后台输出 xml 的方式，而 flex httpservice 等组件对 xml 的良好支持，以及 actionscript3 新的 E4X 语法，将两者结合起来，以 xml 作为前后台数据传输的单元，这对我而言简直就是天作之合。当然有这种类似想法的不止我一个， Peter Armstrong 写的这本《Flexible Rails》就是对这两种技术如何结合的最好总结。它为我们学习如何使用 flex 和 rails 做 RIA 应用提供了一种正确系统化的方法。无论你是 rails 和 flex 的初学者，还是有过一定经验的用户，这本书都非常适合你。对我个人而言第十一章 Refactoring to RubyAMF 就已经可以值回本书的价格了，rubyAMF 为我们提供了另外一种更高效的二进制传输格式和模板，相信它将成为采用 rails 做服务端的 flash 应用的一个标准。另外以我个人的经验，当你熟悉了 flex 后，开发应用的效率将会很高，但是也很容易让自己 rush into code, 如何规划和布局你的代码就成了程序员要解决的问题了，也许是 adobe 也看到了这一点，于是它将 Cairngorm 框架揽到自己的旗下。如果说这本书对我而言有什么遗憾的话，那就是它采用了 Cairngorm 这个半官方的框架，而不是我更喜欢的 PureMVC。 在开发“汤匙”的时候我曾经用 Cairngorm 重构过一个版本，但是很快放弃了它，而采用了 PureMVC，但这只是我的个人选择。相信会有越来越多的 actionscript 和 flex 的框架将出现在我们的面前，比如最近才刚刚兴起的 Mate 框架。 无论你采用什么框架，还是使用自己的 Homemade 方式来整理代码，规范化你的 AS, mxml 代码都是作为一个 flex 程序员必须做的工作。 《Flexible Rails》一书为如何使用 Cairngorm 开发应用提供了丰富的信息，包括一些有益的 tips, 比如使用 Cairngorm generator 简化代码生成。

 

对于那些想入门 flex 和 rails， 想投身到基于 Flash RIA 应用的程序员来说，《Flexible Rails》都是一本必读的书。 在 RIA 领域中， JavaFX 刚刚出来，而且未来也随着 Sun 的被收购而变得很不乐观， Silver light 无论在成熟度和应用案例上都无法和 Adobe Flex 相提并论， 所以有理由相信越来越多的程序员会选择 Flex 作为他们踏入 RIA 领域的工具，那么你还等什么呢，敲门砖就在这里。