Shale是一个基于JSF的web开发框架。它是由Struts的创始人、JSF专家组成员Craig McClanahan发起的。 Shale 的意思是“页岩”。简而言之，Shale 出自这样的思想：Web 框架如果以按功能划分的、松散连接的 “层” 的形式存在，则最为有效。每一层基本独立于其他层，并且关注于一个专门的方面。这一点类似于海岸附近基本上由页岩组成的地质沉积，因此这种新框架就被命名为 Shale！

Shale 加入的新特性

Shale 为什么没有成为 Struts 的新版本

选择JSF而不选Struts的十大理由：(1.Components(组件) 2.Render Kit 3.Renderer)

Shale 加入的新特性

Shale重用了大量的Struts基础代码，因此可以称Struts为它的"父"框架，但Shale是面向服务架构，它与Struts最大不同之处在于：Struts与JSF集成，而Shale则是建立在JSF之上。 Struts实质上是一个巨大的、复杂的请求处理器；而Shale则是一组可以以任何方式进行组合的服务。此外Shale加入了一些新的特性比如：

1.与Spring框架相集成可以使用Spring的依靠注入机制来创建JSF Managed bean。

2.提供一种可选的类似于Tapestry与Facelets使用纯HTML来定义视图。

3.提供测试框架,一组mock object和JUnit test case基类可以帮助测试自身框架的classe和在构建在该框架之上的应用组件。

4.提供AJAX的服务端支持。

5.Tiger扩展等。

Shale不是Struts的补充，而是一个全新的web框架。

总的来说，我们建议在新项目中优先考虑JSF。虽然常常有一些商业上的因素迫使我们为现有的项目选择了Struts，而且那些解决方案还有待考验，但是，让我们面对一个事实：JSF比Struts好多了。

Shale 为什么没有成为 Struts 的新版本

要理解 Shale 为什么没有成为 Struts 的一个新的发行版，首先需要理解关于新软件发行的一两件事。对于一个新的软件发行版，大多数用户首先看的是一组新的特性。版本升级的幅度越大，用户对新特性的期待就越大。因此，如果软件版本从 2.1 升级到 2.2，就应该有一些新的特性，但是如果从版本 2.2 升级到版本 3.0，那么就应该有很多 新特性。这就是为什么当一些大型产品（例如 Microsoft Word）或操作系统（例如 Windows 和 Mac OS X ）出了新版本的时候，用户总是对它们很挑剔。对于每一个新的发行版，用户总是期待有更多新的特性。

由于大多数用户一味地将注意力放在特性上，他们没有意识到向后兼容性（backward compatibility）才是真正最有价值的东西。虽然每个人都希望 Excel 中加入新的、很好的选项，希望 Panther 与 iTunes 有更好的集成，希望 Gnome 中对 XUL 有更好的支持，但是如果那些用户现有的程序和文件在新版本下突然不能运行的话，相信他们会尖叫，“这是血腥谋杀”。在这种情况下，新特性毫无价值。

对于 Struts 也一样。一般来说，Struts 的每个新版本都增加了新的特性，同时保持了与之前版本的向后兼容性。此外，新版本的 Struts 还需要支持旧版本的 Java 平台和 Servlet 规范，因为已安装的旧的 Struts 要在这些平台上运行。这两个需求 —— 向后兼容性和对旧版本的 Java API 的支持 —— 对于 Shale 来说已经是一个严重的约束。尤其是，至少就 Java 平台而言，JSF API 已经成为 Web 的中心组件。虽然 Struts 也支持 JSF，但是 Shale 却是完全依赖于 JSF 的 —— 这对于需要维持向后兼容性的 Struts 来说简直是不可能的。

最后，派生出一个像 Shale 这样的新项目，同时继续在 Struts 这种已有的项目上进行开发活动，这样做具有无与伦比的优势。如果 Struts 只是简单地升级到 2.0（或者 3.0 或 4.0），并在不考虑向后兼容性的情况下实现 Shale，那么对于很多人来说，由此造成的移植工作将是令人痛苦的，可能有人干脆连 Struts 也不再使用了。即使仍然维护更旧的代码基，也难于吸引开发人员花时间来修复 bug，他们也不愿意为一个 “遭到废弃” 的或者 “旧” 版本的软件增加特性。

由于这些原因，让 Shale 成为一个全新的项目，使其建立在一个新的代码基之上，是很有意义的。

选择JSF而不选Struts的十大理由：

1.Components(组件)

组件是Struts和JSF之间最大的区别。就像Swing一样，JSF提供丰富的底层构件去开发组件然后添加到标准的组件集。那些底层构件让你很容易的生成自己的组件并且和别人共享。现在我们到处都能看到自定义组件跳出来，比如说Oracle的ADF和MyFaces，两者都提供了丰富的组件集，就像javascript日历，tree等等。

当然，组件只是一部分。典型的是，组件都和一个独立的renderer对应，这给我们带来了真正的好处（看第3条）。但是和JSF中的很多东西一样，你不一定要墨守成规。只要你愿意，你可以实现render自己的组件，虽然这样你会失去给组件加入别的renderer的能力。

2.Render Kit

在几年前我曾经有份Struts咨询工作，我们必须同时支持浏览器和无线设备，非常痛苦。但是用JSF来完成那个任务非常容易，因为你可以生成你自己的render kit－为一种特定显示技术的renderers的集合－然后配置到JSF里面。

3.Renderer

你有看过Struts的标签的源代码吗？它直接生成HTML。JSF组件标签什么都不生成，它和服务器上的一对component-renderer对应。Component维护组件状态，rendered负责获得视图。重点是renderers是可插拔的，即你可以根据自己需求实现然后替代掉默认实现。比如说我在NFJS上面的Felix谈话中举例说明了怎么去实现一个自定义的label renderer。你只需要配置你的renderer，JSF就会自动在你的应用程序里面使用他。

4.Value Binding Expressions（值绑定表达式）

在Struts中，你负责把数据从Form传递到模型对象。你实现的Action的execute方法是把Form作为一个参数。然后你再手动的把数据从Form Bean里面取出放到模型对象里面。你要为应用里面的每个Form做这些事情，然而在JSF里面，你只需像这样：#{model.property} 就够了，其他的交给JSF来处理。

5.Event Model（事件模型）

JSF的事件模型使你可以对值改变，动作，JSF生命周期阶段变换等作出反应。在JSF1.1中，那些事件都是在服务器端处理的，这肯定是一个缺陷，好在JSF2.0计划支持客户端事件，拭目以待吧。

6.Extensibility(可扩展性)

这个很重要。JSF有6个对象实现了这个框架的大部分功能，而且你可以很容易的用你自己的实现代替原有实现。比如你想加一个自定义参数在JSF表达式语言里面，或是添加一个自己的视图控制器以便于区分组件和HTML。事实上Shale实现了上面的功能。如果你还没有满足，JSF提供了几个地方你可以轻松的控制JSF的生命周期。Shale给你的会更多。

7.Managed Beans(Dependency Injection 依赖注入)

和Spring一样，JSF也使用了依赖注入（DJ）（或控制反转（IoC））去实例化和初始化Bean。Struts的确为你生成了Form Bean和Action Bean，但是JSF可以为你生成各种各样的Managed Bean。

8.POJO Action Methods

Struts的行为是和Struts的API绑定在一起的，但是JSF的行为方法可以在POJPO中实现。这意味着你不用在表单和模型对象之间实现一个多余的行为层。顺便说一下，在JSF里面没有行为对象，行为在模型对象中实现。

但是也请注意一点：如果你愿意你也可以生成与JSF独立的行为对象。在Struts里面，你有Form Bean和Action Bean。Form Bean包含数据而Action Bean包含逻辑。OO狂会想去合并前2者，在Struts你办不到。但是在JSF中，你可以分开数据和逻辑，也可以合并到一个对象中，一切由你决定。

9.JSF is the standard(JSF是标准)

J2EE5.0要提供一个JSF的实现，这表明JSF不久将会无处不在。这可能与你无关，但是和工具供应商密切相关。现在大概有50个Java web应用程序框架，工具供应商不会情愿去支持一个特别的框架，但是他们会毫不犹豫的去支持一个标准。

而且不止供应商，开源项目也会迅速的聚集在JSF的四周，争先恐后的去实现相同的功能。比如说，直到我们去实现本质上和Shale的Tapestry差不多的视图的时候，我才知道Facalets。（从长远来看，我相信这种冗余是件好事，会给我们带来好处）

10.There's only one Struts(只有一个Struts)

Struts是一个开源产品，然而JSF是一个标准。这个细节常常被新的JSF学习者忽略，其实这是显而易见的，因为我们有多个JSF的实现。虽然JSF还很不成熟，但是我们已经有了2个优秀的JSF实现可以选择：Sun的参考实现和Apache的MyFaces。另一方面，我们只有一个Struts。