shale(一個基於JSF的web開發框架)

Shale是一個基於JSF的web開發框架。它是由Struts的創始人、JSF專家組成員Craig McClanahan發起的。 Shale 的意思是“頁岩”。簡而言之，Shale 出自這樣的思想：Web 框架如果以按功能劃分的、鬆散連線的 “層” 的形式存在，則最為有效。每一層基本獨立於其他層，並且關注於一個專門的方面。這一點類似於海岸附近基本上由頁岩組成的地質沉積，因此這種新框架就被命名為 Shale！

基本介紹

• 中文名：shale
• 創始人：Struts
• 意思：頁岩
• 定位：Web套用框架

基本介紹

shale是在 Struts 之後，發展起來基於 JAVA 語言Web套用框架。

特點

要理解 Shale 為什麼沒有成為 Struts 的一個新的發行版，首先需要理解關於新軟體發行的一兩件事。對於一個新的軟體發行版，大多數用戶首先看的是一組新的特性。版本升級的幅度越大，用戶對新特性的期待就越大。因此，如果軟體版本從 2.1 升級到 2.2，就應該有一些新的特性，但是如果從版本 2.2 升級到版本 3.0，那么就應該有很多 新特性。這就是為什麼當一些大型產品（例如 Microsoft Word）或作業系統（例如 Windows 和 Mac OS X ）出了新版本的時候，用戶總是對它們很挑剔。對於每一個新的發行版，用戶總是期待有更多新的特性。

對於 Struts 也一樣。一般來說，Struts 的每個新版本都增加了新的特性，同時保持了與之前版本的向後兼容性。此外，新版本的 Struts 還需要支持舊版本的 Java 平台和 Servlet 規範，因為已安裝的舊的 Struts 要在這些平台上運行。這兩個需求 —— 向後兼容性和對舊版本的 Java API 的支持 —— 對於 Shale 來說已經是一個嚴重的約束。尤其是，至少就 Java 平台而言，JSF API 已經成為 Web 的中心組件。雖然 Struts 也支持 JSF，但是 Shale 卻是完全依賴於 JSF 的 —— 這對於需要維持向後兼容性的 Struts 來說簡直是不可能的。

由於大多數用戶一味地將注意力放在特性上，他們沒有意識到向後兼容性（backward compatibility）才是真正最有價值的東西。雖然每個人都希望 Excel 中加入新的、很好的選項，希望 Panther 與 iTunes 有更好的集成，希望 Gnome 中對 XUL 有更好的支持，但是如果那些用戶現有的程式和檔案在新版本下突然不能運行的話，相信他們會尖叫，“這是血腥謀殺”。在這種情況下，新特性毫無價值。

最後，派生出一個像 Shale 這樣的新項目，同時繼續在 Struts 這種已有的項目上進行開發活動，這樣做具有無與倫比的優勢。如果 Struts 只是簡單地升級到 2.0（或者 3.0 或 4.0），並在不考慮向後兼容性的情況下實現 Shale，那么對於很多人來說，由此造成的移植工作將是令人痛苦的，可能有人乾脆連 Struts 也不再使用了。即使仍然維護更舊的代碼基，也難於吸引開發人員花時間來修復 bug，他們也不願意為一個 “遭到廢棄” 的或者 “舊” 版本的軟體增加特性。

由於這些原因，讓 Shale 成為一個全新的項目，使其建立在一個新的代碼基之上，是很有意義的。

優勢

Components

組件是Struts和JSF之間最大的區別。就像Swing一樣，JSF提供豐富的底層構件去開發組件然後添加到標準的組件集。那些底層構件讓你很容易的生成自己的組件並且和別人共享。現在我們到處都能看到自定義組件跳出來，比如說Oracle的ADF和MyFaces，兩者都提供了豐富的組件集，就像javascript日曆，tree等等。

當然，組件只是一部分。典型的是，組件都和一個獨立的renderer對應，這給我們帶來了真正的好處（看第3條）。但是和JSF中的很多東西一樣，你不一定要墨守成規。只要你願意，你可以實現render自己的組件，雖然這樣你會失去給組件加入別的renderer的能力。

Render Kits

在幾年前我曾經有份Struts諮詢工作，我們必須同時支持瀏覽器和無線設備，非常痛苦。但是用JSF來完成那個任務非常容易，因為你可以生成你自己的render kit－為一種特定顯示技術的renderers的集合－然後配置到JSF裡面。

Renderers

你有看過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。

新特性

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好多了。