seam無縫集成：為jsf定做應(yīng)用程序框架(編輯修改稿)
2025-08-03 12:02 本頁面
【文章內(nèi)容簡(jiǎn)介】 將組件框架想象為使用 “pull” 模型，那么這種區(qū)別就很容易理解了。組件框架中的控制器不是預(yù)先處理頁面請(qǐng)求（在基于動(dòng)作的框架中控制器就是這么做的），而是在請(qǐng)求生命周期中作出讓步，在視圖中調(diào)用數(shù)據(jù)提供方法。此外，頁面上的元素，即組件被綁定到事件，這些事件可以觸發(fā)服務(wù)器端對(duì)象（激活后）的方法調(diào)用，從而導(dǎo)致重新顯示相同的視圖，或者轉(zhuǎn)換到另一個(gè)頁面。因此，組件框架也被歸類為事件驅(qū)動(dòng)的。組件框架抽象出用于事件通信的底層請(qǐng)求－響應(yīng)協(xié)議。事件驅(qū)動(dòng)方法的優(yōu)點(diǎn)是可以減少單個(gè)方法在呈現(xiàn)視圖時(shí)需要預(yù)先做的工作。在組件框架中，UI 事件或解析的值綁定表達(dá)式直接導(dǎo)致方法調(diào)用。一個(gè)應(yīng)用程序即使只達(dá)到中度成熟，它通常也需要在任何給定頁面上使用很多不相關(guān)的活動(dòng)。如果將對(duì)所有這些信息的管理全部放入一個(gè)動(dòng)作或者一個(gè)動(dòng)作鏈中，那么勢(shì)必給維護(hù)帶來極大的困擾。因此，開發(fā)人員常常發(fā)現(xiàn)他們的代碼偏離了面向?qū)ο竽Ｐ偷能壍溃炊萑肓诉^程編程模型的泥潭。相反，組件框架將這種工作隔離出來，更自然地加強(qiáng)了對(duì)象的角色和責(zé)任。Seam 與 JSF對(duì)于 JSF 和組件框架的基礎(chǔ)已經(jīng)介紹得差不多了。實(shí)際上 ?? 很多 Java 開發(fā)人員最近發(fā)現(xiàn) ?? 轉(zhuǎn)移到 JSF 并非總是一帆風(fēng)順。采用組件模型會(huì)帶來一些全新的問題，首要的一個(gè)問題是您通常需要試著使應(yīng)用程序符合基于動(dòng)作的 Web。很多時(shí)候，JSF 需要具有像基于動(dòng)作的框架那樣的行為，但是在標(biāo)準(zhǔn) JSF 中這是不可行的，至少不為每個(gè)請(qǐng)求使用 phase 監(jiān)聽器就不行。JSF 的其他主要缺點(diǎn)還包括對(duì) HTTP 會(huì)話的依賴過重（尤其是在一序列的頁面之間傳播數(shù)據(jù)時(shí)），簡(jiǎn)陋的異常處理，缺少書簽支持，以及太多的 XML 配置。通過與 JSF 自然地集成，同時(shí)加入 JSF 規(guī)范委員會(huì)放棄的或者忽略掉的新功能，Seam 解決了很多這樣的問題。Seam 的框架鼓勵(lì)使用緊湊的、易讀的、可重用的代碼，并且避免了所有為解決上述問題而常常加入的 “粘連（glue）” 邏輯。圖 3 涵蓋了 JSF 生命周期中用于簡(jiǎn)化應(yīng)用程序代碼的大多數(shù) Seam 擴(kuò)展點(diǎn)：圖 3. Seam 生命周期增強(qiáng)讓我們來考慮其中一些增強(qiáng)，因?yàn)樗鼈冞m用于 JSF 開發(fā)中一些常見的挑戰(zhàn)。并不復(fù)雜的配置Seam 演示了 Java 5 注釋的一個(gè)非常實(shí)用的用法。Seam 的部署掃描程序檢查所有包含 文件的歸檔文件，并為所有標(biāo)有 @Name 注釋的類創(chuàng)建一個(gè) Seam 組件。由于 Java 語言缺乏用于在代碼級(jí)添加元數(shù)據(jù)的一種公共語法，因此需要設(shè)計(jì)很多 XML 配置。當(dāng) Java 5 規(guī)范中加入注釋后，就獲得了一個(gè)更好的解決方案。由于大多數(shù) backing bean 是為了在特定應(yīng)用程序中使用而開發(fā)的，因此沒有理由將這些 bean 的配置 “抽象” 到類本身以外的任何文件中。附帶的好處是，您可以少處理一個(gè)文件。Seam 提供了一組完整的注釋來幫助將 bean 集成到 JSF 生命周期中。清單 4 顯示了其中一些。頁面動(dòng)作和 RESTful URL在不使用組件框架的情況下，另一個(gè)必須解決的熟悉的問題是預(yù)先處理每個(gè)請(qǐng)求，就像在基于動(dòng)作的框架中那樣。受此影響的用例是 RESTful URL、書簽支持、通過 URL 模式獲得的安全性以及頁面流驗(yàn)證等。這也是學(xué)習(xí)使用 JSF 的開發(fā)人員容易感到困惑的主要原因之一。有些 JSF 供應(yīng)商通過用開發(fā)人員工具提供 onPageLoad 功能來繞過這個(gè)問題（見 參考資料），但這不是核心規(guī)范的一部分。當(dāng)用戶直接從書簽（比如）請(qǐng)求一個(gè)商品詳細(xì)信息屏幕時(shí)，通常會(huì)發(fā)生什么事情呢？由于 JSF 控制器采取被動(dòng)方式，當(dāng)頁面開始呈現(xiàn)時(shí)，即使明顯沒有目標(biāo)數(shù)據(jù)，也不能將用戶重新帶到邏輯流的開始處。相反，這種情況下只能顯示一個(gè)空頁面，其中只有一些空值或其他可能存在的假信號(hào)。首先，您可能會(huì)本能地想要在頁面的主 backing bean 上實(shí)現(xiàn)一個(gè) “divrender” 方法。然而，在組件框架中，backing bean 與頁面之間的關(guān)系并不一定都是一對(duì)一的。每個(gè)頁面可能依賴于多個(gè) backing bean，每個(gè)那樣的 bean 也可能在多個(gè)不同的頁面上使用。必須用某種方式將一個(gè)視圖 ID（例如 /user/）與一個(gè)或多個(gè)方法關(guān)聯(lián)起來，當(dāng)選擇呈現(xiàn)相應(yīng)的視圖模板時(shí)就調(diào)用這個(gè)（些）方法。您可以使用 phaselistener 方法，但是這仍然需要定制的邏輯來確定對(duì)于當(dāng)前視圖和階段是否應(yīng)該執(zhí)行該功能。這種解決方案不但會(huì)導(dǎo)致很多冗余邏輯，而且會(huì)將視圖 ID（很可能是應(yīng)用程序中最不確定的部分）硬編碼到編譯后的 Java 代碼中。頁面動(dòng)作來幫忙Seam 的頁面動(dòng)作可以幫助您預(yù)先攔截呈現(xiàn)的假信號(hào)。頁面動(dòng)作是使用方法綁定指定的，方法綁定在進(jìn)入頁面時(shí)、Render Response 階段之前執(zhí)行。對(duì)于 /WEBINF/ 配置文件中一個(gè)給定的視圖 ID，可以配置任意數(shù)量的方法綁定。（或者，可以通過將它們放在視圖模板鄰近的一個(gè)文件中，復(fù)制它的名稱，但是將文件擴(kuò)展名換為 *.，從而分解每個(gè)頁面的定義）。對(duì)于頁面動(dòng)作，XML 是有必要的，因?yàn)橐晥D ID 非常容易變化。就像 JSF 通過 Apply Request Values 階段的值綁定將 post 數(shù)據(jù)映射到模型對(duì)象一樣， Seam 可以通過執(zhí)行頁面動(dòng)作之前的值綁定將任意請(qǐng)求參數(shù)映射到模型對(duì)象。這些請(qǐng)求參數(shù)注入的配置嵌套在頁面動(dòng)作 XML 聲明中。如果頁面動(dòng)作方法調(diào)用返回一個(gè)非空字符串值，則 Seam 將其當(dāng)作一個(gè)導(dǎo)航事件。因此，不必遷移到一個(gè)完整的基于動(dòng)作的框架中，仍然可以比得上最特別的特性。Seam 包括很多內(nèi)置的頁面動(dòng)作，它們通?？鐟?yīng)用程序使用。其中包括用于驗(yàn)證 conversation 是否建立的一個(gè)動(dòng)作；可以啟動(dòng)、嵌套和結(jié)束 conversation 的動(dòng)作；處理預(yù)期異常的動(dòng)作；以及確保適當(dāng)?shù)膽{證的動(dòng)作。頁面動(dòng)作是啟用對(duì) JSF 的書簽支持的關(guān)鍵。Seam 的創(chuàng)立者允許在進(jìn)入頁面時(shí)請(qǐng)求參數(shù) actionMethod 觸發(fā)一個(gè)方法調(diào)用，從而利用了這一特性。更妙的是，您不需要做任何額外的工作就能為書簽創(chuàng)建鏈接。 Seam 提供了兩個(gè)組件標(biāo)記：s:link 和 s:button，用以處理細(xì)節(jié)。這兩個(gè)標(biāo)記分別對(duì)應(yīng)于
教學(xué)教案相關(guān)推薦
鄂ICP備17016276號(hào)-1