创业公司 Lovely Charts 谈如何构建 Flex 应用

  • Moxie Zhang
  • 宋玮

2008 年 2 月 1 日

话题:Java语言 & 开发架构

Lovely Charts是一家 Web 创业公司,它宣布了其受限的 beta 版,并于上星期发布。该站点是使用 Adobe Flex 开发的。InfoQ 采访了 Jerome Cordiez,该网站的奠基人及首席架构师,并了解到了基于 Flex 的 Lovely Charts 站点是如何构建的内幕信息。

Cordiez 一开始介绍了 Lovely Charts 的功能:

Lovely Charts 是用 Flex 构建的一个在线图表应用,允许创建各种专业感观图表,比如流程图(flowcharts)、站点地图(sitemaps)、组织图(org. charts)、网络图(network diagrams)、线框图(wireframes)等等。这些都是免费的

所以,Lovely Chart 是一个在办公工具,类似 Microsoft Visio。那么,创造这一新产品的背后动机是什么?Cordiez 回答道:

基本上,最初的动机来自我自己的需求和挫折。我相信大多数人都面临同样的问题,我不会去做大量的图表,但是我时不时地会偶尔画那么几张图表……因此,我一直寻找一种工具来帮助我,但实际上从来没有找到真正适合我需求的工具,这促使我去做这件事,并去研究为什么我对现有的解决方案不满意,以及我到底在寻找什么。通过这一过程,我建立了一个我称之为项目幕后核心驱动力的一个列表,并开始构建第一个 POC 原形……

为了了解更多该站点的创建过程,InfoQ 询问了其主要设计目标。Cordiez 给出了其中三个目标。第一个目标是:

易于使用。我想要一个很容易使用的工具,让你几乎忘掉绘制过程,将注意力集中在你要展现的东西上而不是如何去画它。

接着 Cordiez 就易于使用程度给出了一些想法:

我这里谈论的不只是可用性,而且是易用性,我也谈及了不用费劲、不必具备设计知识就能创建优秀的外观素材,因为那些由应用程序来提供。

第二个目标是:

迷人。对某些人来说这听起来并不重要,但是我认为这是最基本的。我们绘制图表不是为了好玩。我们绘制图表是因为需要与其他人交流。我们需要打动、吸引、说服……客户、合作伙伴、同事、教师……基本上图表只是用于交流。如果你有适当的可视材料做辅助,我绝对相信交流可以更加容易、更加有效。

第三个目标是:

非侵入的。关于这一点我想简单地引用一下37 Signals:“每个人都喜欢能帮助完成工作的简单工具,而且这种工具召之即来挥之即去。”

关于构建 Love Charts 的技术方面,Cordiez 总结道:

自始至终使用的都是 Flex,将 Flash 用于类库编译。我还没有看到任何类似于 LC 的东西是用 Ajax 来构建的。中间层是 Flex(Actionscript 3 和 MXML)、PHP/MySQL、以及 AMFPHP。一个基于 Cairngorn 框架的直接地客户端架构。

AMFPHP(PHP 远程解决方案)处理后台和前台之间的通信。这考虑到一个优雅的、易于维护的、相当透明的 OO 架构,在这里你拥有真实类型的、无缝游历与前台和后天之间的对象。

从架构的角度看,有什么东西本可以做得更好或者与众不同?Cordiez 并不介意分享他的遗憾:

我唯一遗憾的是在 PHP 层与数据库之间没有实现某种类似 ActiveRecord 的框架。我知道一些人正在为 PHP 做这项工作,但是当我研究它之后,发现它既不适合消费也不满足我的需求,我只是缺少时间完成我自己的解决方案。

在 RIA 系统方面,是什么让 Lovely Charts 区别于传统的 Web 应用,以及其架构又将如何发展呢?Cordiez 分享了他的观点:

Lovely Charts 目前的特质使它非常接近于“纯客户端”应用……我的意思是,目前应用程序 90% 的逻辑在客户端,后端只执行最基本的类 CRUD 操作,所以目前这还不是真正的问题,但是随着计划更多的向协同应用方向发展,后端的重要性必然会增加,其架构也必然需要做出修正以适应新的功能。

InfoQ 询问了在 Lovely Charts 开发期间,所遇到的技术挑战是什么。Cordiez 回忆起一个他所认为的真正挑战:

正确的处理键盘快捷键是我所碰到的最大挑战。早期测试者的反馈表明,人们期望提供标准快捷键,比如 Ctrl-Z、Ctrl-C 等等,这是正当的要求。但是一开始听起来这肯定太不简单了。

Cordiez 进一步解释了问题所在:

首先,即使 ActionScript 语言提供了传统的 DOM 键盘事件处理机制,当前也没有一个可以用于应用级实现的、易于维护的、实现了按键处理系统的标准框架。现在好了,这已经是应用开发者工作的一部分了,而且这也是一个有趣的挑战。

Cordiez 继续分享着 Flex RIA 应用开发的困难和挑战:

但是,一旦你有了一个在独立配置中可以很好工作的基本框架,由于 Flex 应用仍是 Web 方式、嵌入浏览器的,你还将面临浏览器兼容问题。这时你通过合并一些能解决特定问题但缺乏全局观的技巧来打碎你的架构。接着你破坏了早期还能工作的东西,等等等等。依我看来,这是一个不断受挫的过程,即使我知道有些人欣赏这种类型的挑战 :)……当你正在构建一个 Web 站点时,跨浏览器兼容的技巧是可以接受的,但是对于复杂应用,这不是你真正想去处理的问题,也不是你不得不处理的问题。

虽然挑战就在面前并且需要处理,Cordiez 仍对将来持乐观态度:

目前,这是经典的 RIA 挑战,我知道其他项目(比如 buzzword)也曾面对这一挑战而且显然已经以一种较为满意的方式解决了大部分问题,我相信 Lovely Charts 的键盘快捷键问题迟早会标准化并工作良好,但现在它仍是个挑战……我不知道将来 Adobe 打算如何处理这一问题,因为即使他们的安全问题真正完美有效,有点也是事实:如果 Flash 平台标榜自己是 RIA 开发者的不二选择,就必须解决这一问题。

Cordiez 接着谈及了在 Flash/Flex 平台上开发的经历:

除了这个,我没有遇到任何特殊的技术挑战,对我来说最大的挑战是规划出交互原则和机制,以帮助提供一种令人满意的新绘图方法……我必须要讲的是,Flash 平台绝对是好东西,因为你可以马上干净地搞定一些概念验证,构造整个原型的过程非常敏捷,而且一旦你决定用它实现一些“现实的”东西,它还可以构建出一些非常干净且健壮应用程序。这种灵活性,结合 Flex 框架的强大能力以及它所提供的一切,确实使这一平台成为 RIA 领域一个非常高效的平台,可用于更丰富更友好用户体验的概念和实现。

最后,Cordiez 向 InfoQ 展示了他所规划的 Lovely Charts 未来:

我期盼 / 希望截至 2008 年一季度,能够出来第一版,或者至少是个开放的公共 beta 测试版。而且,虽然现在详细讨论它还为时尚早,但是 Adobe 的 BlazeDS 绝对是个好东西。

关于版本 2 或更高版本,Cordiez 透露道:

版本 2 将主要集中在增加协作能力(或许是实时的)和“用户生成内容”选项,应许高级用户创建自己的库,最终共享出去等等。

版本 2 的另一个任务是改进高级功能:实时协作或许是其中的一个方面,但是我还着重考虑将 AIR 作为增强版本的部署平台,利用像桌面集成、离线同步和存储等等等等……同时保持 Web 解决方案提供的内存消耗小,以及“多平台主义”优势。

我所考虑的另一个选项是开发一些针对于专门角色或专门行业的专用 / 高级选项,但是这个优先级不是很高,我猜用户反馈和需求将决定是否特工这些选项。
InfoQ 将继续报道使用 RIA 技术开发的新的在线业务的相关新闻。

查看英文原文:Startup Lovely Charts Shares Insights into Building a Flex Application

Java语言 & 开发架构