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