JSF專案中seam的配置

JSF專案中seam的配置
　　文章裡主要是把seam在jsf中的使用經驗提一下，能讓更多的人瞭解seam的實際應用和優勢。
      1.seam配置時要注意的地方：
　　(1)faces-config.xml裡面要加入一個seam的階段監聽：
     
      org.jboss.seam.jsf.SeamPhaseListener
      <!-- com.future.egov.jsf.ext.event.DebugPhaseListener --&gt
     

　　seam動起來的條件就是從這裡發起的，seam通過這個監聽器對jsf的各個階段進行必要的增強以及植入自己的CONVERSATION生命週期，對於這個監聽器的具體細節工作，我還需要更多時間研究,仍在瞭解中!

　　(2) 一定要在工程類路徑的根下放置一個seam.properties檔案，你可以設定為空內容，主要是引導seam在初始化的時候載入這個路徑下所有標註為seam元件的物件（通過@Name註釋），http://www.ibm.com/developerworks/cn/java/j-seam1/ seam無縫整合jsf給我了提示！

　　(3)web.xml下最小配置是加入seam監聽器
     
      org.jboss.seam.servlet.SeamListener
     

　　在容器載入工程的時候，初始化seam框架。

　　以上三處的配置，你就可以在任何容器中使用seam了！更多的配置大家可以找參考瞭解吧，我目前在專案中就使用了以上配置。其他配置主要是在seam對ajax，ejb3的支援上，不過seam很新，什麼事都會發生！

　　2.常用的註釋：（所有被seam定義的領域物件都可以認為是seam元件）

　　（1）@Name(XXX)，需要在你的領域類上定義，定義了seam元件的名稱，對於jsf來說就是backing-bean，也就是說你不用在faces-config中配置managedbean了！

　　（2）@Scope(ScopeType.XXX)，可以在你的領域類上定義，表示這個被定義的seam元件在什麼上下文中，jsf中主要包括page,event,session,application,conversation這些Scope。我在專案中主要使用event,session,conversation。event就是把元件放入了request中，session同理，conversation是seam獨創的聲命週期，conversation短聲命週期類似request，但是會儲存一些jsf容易在請求中丟失的資料（jsf只是儲存元件，不儲存元件渲染的資料，除非是EditableValueHolder元件，有時候需要通過myfaces的save元件和updateActionListener元件來恢復這些資料），具體儲存細節，需要看使用的情況，我有這樣一個經驗：當定義成event上下文，在頁面的一次請求中，有些資料請求時還在，但是到渲染時就不見了，? 赿ataTable元件，myfaces的commandNavigation元件，但是換成conversation上下文，這些資料在渲染時又找回來了。但是對於跨度比較大層面，我還是推薦使用myfaces提供的保持機制，我一般使用updateActionListener，而save元件在seam1.2.1的環境下會出錯。如果再有更大跨度，就可以使用conversation上下文的長會話了。

　　（3）@Begin（join=true）,@End(beforeRedirect=true)，當觸發了帶有@Begin標記的方法，conversation的長會話就這樣開始了，主要是為了長時間使用已經載入到conversation域中的物件或者屬性（如果定義了conversation但並沒有載入的可不算）：join=true就是告訴你會話中有同名值時繼續賦值，還有一個註釋引數ifOutcome=XXX，就是看你的方法返回的字串是否和ifOutcome定義的字串相匹配，如果匹配就開始長會話。當在長會話期間執行到某個方法帶有@End標記那麼這個長會話就會結束，這樣防止了記憶體洩漏問題，我認為這是一個權衡的結果，也許使用者真的會點選那個帶有結束標記方法的按鈕。beforeRedirect為真就會在結束時清掉conversation上下文所有的資訊，如果beforeRedirect=false，conversation只是變成短會話，在結束後的那次請求中還可以使用conversation中的資料，一般會用在messages提示這個應用場景中使用，但是如果要返回資料列表有時就需要清空所有資料，防止資料列表還會重現長會話開始前的情況。

　　（4）In(value=XXX,rquest=false,ScopeType=XXX)，Out(value=XXX,rquest=false,ScopeType=XXX) seam把它定義為雙射。In是最常用的標註，你可以使用In匯入一個jsf的EL變數來獲取jsf模型，例如我要獲取spring的業務bean，而且業務bean已經定義成backing bean，利用spring與jsf整合的方法：

          <!-- Managed Beans for options.jsp --&gt
         
         
          org.springframework.web.jsf.DelegatingVariableResolver
         
         
          gbk
         
          resources/MessageBundle
          <!-- com.icesoft.faces.facelets.D2DFaceletViewHandler
          --&gt
         

　　在seam元件中這樣宣告：
      @In(value="#{userService}", request=false)
      private UserService userService;

　　這個示例為seam元件注入了由spring管理的使用者服務物件，它的value是從jsf EL變數中獲取，request=false在告訴seam，如果當前的值沒有找到，那麼設定為空，否者當出現沒有找到的情況，seam會丟擲空異常。
@Out屬性主要是把處理過的屬性值會由seam重新再付給上下文也就是Out中所定義的ScopeType上下文，我認為雖然是seam的一個特點，但是在我的應用中不多，主要是注入而非雙射！如果它真的能在短期Conversation中有所作用來代替Myfaces的資料保持機制，我想會好些，我目前只是在長Conversation有所應用。

　　3 .@Factory，@DataModelSelection，@DataModel，它們主要來代替資料列表的使用，主要是減少了程式碼量，Factory是在請求值階段就對需要例項化的物件進行建立，DataModelSelection定義的屬性，可以透明的抓取資料列表選擇的單行資料，DataModel屬性減少了不必要的get，set。然而我在實際的使用中由於很多不定的情況，大部分的使用上又回到jsf標準的get方式。 這種開發方式我認為seam的目的是想遮蔽與頁面不必要的關係細節，讓開發只需要重視真正的業務，是一個標準的物件導向式結構，當jsf的體系結構的不斷優化，類似這種開發方式我想會越來越有用。

　　4. @RequestParameter是個很有用的註釋，它自動把當前屬性和頁面同名的request提交值繫結在一起，雖然這樣使用違背了jsf所追求的物件導向化，http透明化，但是實際開發中會後很多意想不到的情況，有時候在整合式頁面這樣的做法會很有用，當你的頁面中不僅僅有jsf標籤就清楚了！

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13270562/viewspace-244074/，如需轉載，請註明出處，否則將追究法律責任。