SmartGWT 1.0：与 Sanjiv Jivan 面对面

上个月早些时候， SmartGWT 发布了 1.0 版本。 SmartGWT 这个 API 允许在构建 GWT 应用时采用 SmartClient Javascript 组件库。SmartGWT 是 Sanjiv Jivan 开发的，他以前还领导过 gwt-ext 的开发，后来由于许可问题而退出了开发团队。

InfoQ 有幸就 SmartGWT 采访了 Sanjiv Jivan，了解他关于这个新项目、该新项目与 gwt-ext 的比较、以及对该项目未来计划的一些看法。

SmartGWT 提供的主要特性是什么？

SmartGWT 为 GWT 提供了 SmartClient AJAX RIA 平台的完整 API。SmartClient 与其他 Ajax 库非常不同，它不仅提供了整套 widget，还处理了一些有关构建企业应用的困难问题：不仅要装载并显示数据，而且要把用户的修改传回到服务器，还要处理这些改变的所有结果——服务器校验及其它错误处理、跨多组件的缓存更新等等。 SmartGWT 的数据感知 widget（data-aware widget）——比如说 Tree、Grid、Calendar 等，提供了完整的端到端用户交互，比如树重新排序（tree reordering）、Calendar 中的拖放事件等，它们都可以自动产生适当的服务器请求以使用易于定制的简单协议来更新数据。本文主要是帮助理解 SmartGWT 所提供价值，更多详细介绍请参见这里。

另外几个值得提及的特性包括：

• SmartGWT 支持 **在线grid ** ，它不仅能够按需从服务器延迟装载数据行，还可以在用户拖动水平滚动条时延迟数据列展现。大多数浏览器不能够应付表格中大量数据列展现，也不具备 SmartGWT grid 在不影响性能情况下轻松展现大量数据的延迟展现能力。TreeGrid 支持多列、可编辑、延迟加载的结点，十分强大的垂直滚动特性以及许多应用所需的一些东西。
• grid 中的自适应排序及过滤是非常好的特性。当被过滤的数据已经下载到尺寸相当的本地缓存里，用户应用的其它过滤操作将不再引起与服务器的交互，此时使用的是本地缓存数据。当履行请求所需的数据不在本地缓存中时，它将透明地恢复对服务器的调用。通过减少与数据库的交互并立即响应用户，其响应和性能表现与现实世界中企业应用有很大的不同。
• Relogin：对于需要认证的应用，如果发起请求时会话已经过期，SmartGWT 很容易实现一个工作流，在这里用户会被提示重新登录（relogin）并且在认证成功之后使原来的交易得以恢复，不会丢失数据或上下文。

gwt-ext 和 SmartGWT 的主要区别是什么？

除了底层库所提供的实际功能的明显差异外，在 gwt-ext 中，有相当数量的粘合代码（glue code）是用来“修补”ExtJS API 的不一致及不当的展现行为的。在使用 SmartClient 时，一切都工作的很好。widget 组件层级是一致的且是面向对象的，所以直接迁移到 SmartGWT 结果非常好。 SmartGWT 还使用了标准的 GWT 1.6 事件 API，它与其前身相比非常整洁而灵活。因此用户不再需要应付 listener 适配器类。

另一个重要的区别是，SmartGWT 完全支持 SmartClient，用户可以制作特色请求、加速错误修复、可以获得支持和培训而不用担心碰到障碍。另外，用户还可从商业友好的 LGPL 许可库中得到实惠。这岂不是两全其美。

鉴于 ExtJS 和 SmartClient 的工作经验，你怎么看待这两个组件框架的关系呢？

ExtJS 的确功能强大而且非常漂亮。这也是在 Ext 还是 LGPL 的时候，我启动 gwt-ext 的原因。可是在开发 GWT-Ext 期间，发现在 Ext 中有许多边界情况、陷阱、延缓展现工作区以及不一致的类层级，必须增加一些粘合代码“修补”这些不一致。比如有些布局允许你动态增加新组件，而有那么两个关键布局却不支持。另一个关键问题是有相当比例的 widget 属性在展现之后不能再修改，而有些情况下用户需要设置一些属性，有时他们需要调用方法来完成相同的事情。 SmartClient 已经开发有 8 年了，非常稳定而且事实上没有什么 bug。组件模型是一致的而且在展现之后允许用户动态改变大多数属性并立即反应修改结果。它显然功能更强且处理服务器集成得心应手。如果你去浏览 SmartClient论坛，有些事情就变得很明显了：

1. 你几乎听不到“这个特性是不可用的 / 不被支持的”。用户要求的每一件事几乎都可以满足。
2. 错误汇报数量几乎为零。
3. 你找不到任何没有回复的问题。

如果你浏览了他们 Showcase 的例子源文件，你会注意到另一些事情：用这么少的代码却可以完成如此大量的工作。一个需要发送变更给服务器的主从界面，在传递一个可重用数据源定义时只需寥寥 10 行代码就可解决问题。

对于用户来说，使用封装 SmartClient 后的 SmartGWT 和一个完全重写的相比，你有什么建议？

用户有一个常见的误解：任何用 GWT 编写的第三方库都会如魔法般快速运行，它们是完全无泄漏的，而且在所有浏览器上都能完美展现。以由第三方编写的 TableGrid 为例，它是用 GWT 从头开始编写的，执行起来仍然很糟糕，而且在所有浏览器显示并不一致。当然 GWT 从几个方面可以帮助避免泄露，但是这并不意味着用 GWT 编写的第三方代码就 100% 不会泄露。真正重要的是本框架代码编写得很好，经过仔细调优和很好的测试。 实际情况是 SmartClient 快速且稳定，而且为 SmartGWT 提供了一个非常好的基础。实际上，依我的经验，在解决浏览器不一致方面，SmartClient 其实比 GWT 纯第三方库更胜一筹。SmartClient 提供了精准且一致的跨浏览器布局，其使用一个面向对象的皮肤系统，无需精深的 CSS 经验或浏览器怪癖方面的知识。

五月份，你在博客上发表了一篇博文，谈到由于 ExtJS 有争议的许可变更，你退出了 gwt-ext 项目。这个决定在社区中获得了多大的认可？

社区表示非常理解，而且 gwt-ext 的其他团队领导也已经成长起来并做了很出色工作。最重要的是，社区真正成长起来了，而且看到用户们可以互相帮助感觉非常好。 我已经与 gwt-ext 团队的领导们交流过，他们表示要给那些感觉受 gwt-ext 限制的用户一个可以移植到 SmartGWT 的选择权，这是一个健康的选择。对于那些有兴趣移植的用户，我们将提供帮助。当然 gwt-ext 项目仍将继续以当前的方式运转。

就算你们五月份就开始开发，SmartGWT 发展到 1.0 版本已经很快了。你们在开发 gwt-ext 的过程中有什么经验和教训可以用到 SmartGWT 上吗？

在一个开源项目中工作最主要的是个人满足感，以及在一个被许多用户使用的项目中工作的那种“良好感觉”。帮助个人开发也是一个非常好的学习经历。 在技术方面，我可以把开发 gwt-ext 过程中所学到的东西应用到 SmartGWT 上，而且对用户所面临的问题加以改进。还有一个经验就是：使项目远离政治且发自内心是很重要的。

让人伤神的是我常常会收到来自 Ext, LLC 的 email，威胁如果我不参与他们的计划就要起诉我。比如，他们想让我切换到 GPL 许可协议下，否则他们将认为我违反了他们的许可协议。而且，没有提供任何细节。我还收到过另一个威胁，他们说如果我不允许他们在 gwt-ext 论坛张贴信息，在 24 小时内就会收到他们的律师函。而且这是在我辛辛苦苦构建的项目直接支持了其代码库的成长与销售的情况下，他们还这么干。

相反，SmartClient 的伙计们完全支持 SmartGWT，他们不仅提供技术上的帮助，而且还为 SmartGWT 在其旗下运转提供了一个安全场所。他们甚至还写了一封公开信，声明他们不会改变 LGPL 许可协议。能使用我所认为的出色产品并回到技术工作上，这种感觉太好了。

查看英文原文： SmartGWT 1.0: A Q&A with Sanjiv Jivan