JBoss发布了支持Groovy并增强了JSF的Seam 2.0

今天JBoss Seam团队发布了Seam 2.0。这个版本与上个主版本的发布相隔8个月。项目成员Norman Richard列举了这一版本的主要特性：

• WebServices——Web service可以是会话式的，而且可以利用Seam的组件和服务。
• Groovy——可以用Groovy写Seam组件
• 热部署——在开发模式下，Seam可以热部署组件定义而无需重新部署整个WAR或者EAR。
• 支持Eclipse——在JBossTools中对Seam 2的支持包括项目向导，集成测试，JBoss EL自动完成，视图页面的可视化编辑等等功能。
• 不依赖于JSF——Seam已经与JSF解耦，现在它可以更方便的与其他web框架集成。实验性的与GWT集成的原型已经完成了，我们可以看到Seam如何与GWT协同工作。
• 支持JSF 1.2——Seam已经把它的缺省JSF实现从myfaces切换到JSF RI。
  
• JBoss EL ——Seam提供了对JBoss EL的支持，支持参数化绑定、非JavaBean属性与投影。
• Maven——Seam自己的依赖关系由Maven管理。有一个Maven repository是可用的。
• 集成——Seam可以与许多流行的项目集成，例如Quartz，JFreeChart，Hibernate Search和iText

InfoQ与Seam的项目领导人Gavin King讨论了Seam新的版本。InfoQ的第一个问题是相对与Seam 2.0版，1.0中最大的不足是什么：

我认为在1.0中我犯的最大的错误是：

（1）开发Seam的时候假设使用环境为JSF，EJB3和JTA。这些技术毫无疑问都是非常流行的，但是仍然有很多人要求在其他环境中使用Seam，他们推动我们开放了Seam的实现，现在Seam可以支持其他环境。

（2）没有认识到我们内建的组件库会增长的如此庞大。在早期的版本中，我天真的把所有内建的组件放在org.jboss.seam.core包中。在Seam 2中我们不得不彻底重新组织了包结构。

接下来King比较了JSF组件技术与把整个表现层放在浏览器中的技术，例如ExtJS：

我认为我们主要需要考虑两点：

（1）你喜欢用声明式的方式还是编程式的来定义用户界面？

（2）在客户端到底有多少功能可以被真正执行？

还有一个问题，你希望的类型安全是什么样的。

所有这些问题几乎都是正交的。例如，GWT提供类型安全的，编程式的，客户端的方案。另一方面，Wicket提供类型安全的，编程式的，服务器端的方案。

JSF在某种程度上是类型安全的，声明式的，服务器端的方案，如果需要的话，你也可以选择编程式的方式。每种方式都有它自己的优缺点，但是我认为JSF的方法是强迫性的：

首先，我必须用一种声明式的语言来定义用户界面。用户界面本质上是分层的，而我希望我的代码结构能够反映这种本质。我对于使用swing风格的 代码来建立用户界面总是觉得别扭。这种代码看起来总是很丑陋而且难以维护——有点象通过遍历DOM树来解析XML的Java代码。这里存在基本的结构性的 断层。

对于用户界面中动态性强的部分，编程式的操作当然更有效。但是，动态性强的部分是很少的。除了个人控制级别的界面以外，大多数用户界面是静态的。而JSF 在处理动态性的界面时也是很强大的，它允许你在Java代码中直接操纵JSF组件。当然，你可以选择使用JavaScript代码来操作浏览器中的DOM 对象。（总有一天，有人会建立一个JSF实现，使得客户端可以访问JSF组件树，但是我们现在没有实现这个功能。）

其次，我不认为把更多的状态和应用逻辑放在客户端执行会减少很多开发工作。有太多事情只能在服务器端有效的处理：持久化，安全，数据级别的并发，等等。如 果你把试图把你的应用代码放到客户端，那么你最终会回到我们3、4年前的状态，会有这样一种架构，其特点是：有一个无状态的服务层，一些数据传输对象，细 粒度的手工方式的获取数据以及合并数据变化。这是痛苦的编程模式，我们采用有状态的组件和会话范围的持久化上下文——这两种都是服务器端技术——刚刚从其中逃脱。

使用RichFaces和Seam，你可以创建这样的用户界面：异步的获取数据，交互式的更新视图，异步的响应用户交互，交互式的应用变化，这些动作都处 于一个良好定义的乐观事务中，没有任何烦人的重复工作。当然，学习JSF和RichRaces比使用其他方式要多花一些时间，但是从长期来看这些代价是物 有所值的。

我所认为的JSF方式的最大的弊端目前很少被提及：使用EL把视图绑定到模型时缺乏类型安全。我理想的环境应该支持一种真正类型安全的声明式语言来定义用户界面。可惜，Java不能真正支持创建这样的DSL。遗憾。

InfoQ然后询问了关于新的Web Beans JSR的话题：

Web Beans有许多思想是从Seam得来的：

• 上下文相关的组件
• 会话
• 按照优先级规则的组件覆盖
• 与Java EE的深度集成
• 基于注释绑定的拦截器绑定
• 事件通知

与此同时，Web Beans还从Guice"剽窃"了基于注释绑定的依赖注射思想，这导致了影响深远的后果。

Web Bean集这些思想之大成而形成了一个非常独特的编程模型，该模型强调“松耦合与强类型”。你可以利用Web Bean的优势完成一个非常松耦合的应用：

• 使用上下文相关的生命周期管理（有状态的组件象service一样相互交互）来解耦客户端和服务器端的生命周期
• 使用部署时组件覆盖来解耦客户端与服务器端的实现
• 使用事件通知来解耦消息生产者与消费者
• 使用拦截器来解耦横切（技术上的）关注点

所有这些功能都没有牺牲类型安全。所有的工作都是通过类型安全的注释完成的——没有隐藏起来的字符串，准备在运行时突然咬你一口:-)总的来说，Web Beans建立在Seam的传统之上，但是我相信它是一个更加强制性的模型。我有一个出色的专家组保佑着:-)

最后，我们问起King在使用Seam开发新的运行在in.relation.to上的wiki时，团队是否发现了Seam框架的一些漏洞：

我们发现了一些bug和小的限制。但是开发Wiki带来的最大影响是激励我们为Seam开发一个插件架构。这里我们所指的插件，是类似于portlet那样的东西，只是不那么弱智。

查看英文原文：JBoss Releases Seam 2.0 with Groovy Support and JSF Enhancements

译者简介： 曹云飞，西安交通大学计算机软件硕士。现就职于 Ethos ，热衷于新技术的钻研，软件架构与敏捷开发，目前从事Home Control方面的工作。参与InfoQ中文站内容建设，请邮件至 china-editorial[at]infoq.com。