RichFaces 3到RichFaces 4的遷移

Question

我目前正在研究一個項目，我想從版本3.3.3.Final遷移到RichFaces 4。我想知道...

• 有沒有什麼主要的東西我應該思考或知道或考慮之前遷移？

• （可能是一個愚蠢的問題，但...）你可以「混合」richfaces 3與richfaces 4嗎？

有一個問題我想使開關的主要原因是使用RichFaces 4自動完成，是有沒有辦法做這樣的事情期運用RichFaces的3或將進行遷移的是最簡單的？

我正在使用JSF。

Answer 1

有沒有什麼重要的東西我應該思考，或知道或考慮之前遷移？

他們的建議是按照自己的RichFaces 3.3.x - 4.x Migration Guide —這似乎是遠遠沒有完成，看到EJP's answer below的真實經歷。

---

（可能是一個愚蠢的問題，但是......），你可以 「混合」 的RichFaces 3 RichFaces的4？

不，你不能。它會與自身發生衝突。

Answer 2

這裏注意到官方的移民指南並不比完成約30％更好。作爲一個衡量標準，我在2011年基於遷移指南編寫了378行XSLT樣式表。然後我暫停了這個項目，直到2015年6月，根據進一步的調查並得到它的工作，它已經達到了1090條線。請記住，任何XSLT樣式表都有一些開銷，378/1090 =大約35％。

你做了之後它說什麼的遷移指南：

1. 打開TLD/VLD生成的文檔您在相鄰的瀏覽器標籤，每一個版本中使用的每個組件，並仔細比較。在屬性名稱和用途中有數十個未公開的更改，並且某些屬性已從父容器移至子容器。

2. 也有剛剛取出任意重要的事情，如rich:page和rich:layout.

   我會提供的一些額外的東西我在本月底發現的列表。

3. 然後，你會遇到不愉快的認識，他們也改變了他們自己的樣式類名稱，所以如果你已經爲你自己的樣式表中的任何樣式定義了樣式，你還有更多的工作要做做。

4. 你還會發現他們聲稱你可以定義你自己的樣式類並在豐富的組件中指定它們來實現你自己的樣式，這簡直是不真實的。你的樣式類應用於包含級別，但在許多情況下，例如他們認爲適合在單元級別定義字體等的表格單元格，其中唯一可以覆蓋它們的方式是通過名稱重新定義它們的單元格樣式。
5. 您還必須確保您的樣式表包含在Rich Faces之後。在3.3中，這是自動的，因爲他們首先被包括在內。他們現在包含在最後，因此您必須儘可能晚使用h:outputStylesheet，以確保它在事後生成。

我使用XSLT轉換來實現遷移指南並完成上述1-2。它目前有超過1000條線路，我還沒有完成。爲什麼他們自己不能提供這樣的東西對我來說是一個謎。

爲什麼認爲有必要在版本3和版本4之間進行這樣的重大更改是另一個更深層次的謎團。這是一個管理不善的產品。我不會再遷移它，或者重新部署它。

EDIT無證變化我已經發現（使用XPath語法爲了簡潔）：

• a4j:status

  1. 的文檔上的點模糊，但for=屬性已被刪除：除非通過status=屬性與特定小部件合併，否則它現在默認在最近的父項a4j:region內運行。所以如果你在同一個地區有多個玩家，他們現在都會開火。

  2. 如果您希望通過status=將其應用於特定的窗口小部件，則必須將相應的a4j:status/@id更改爲@name屬性。

  3. 你解決一切之後，它仍然不能正常工作：

     • 的a4j:status與@for（刪除）屬性不會停止
     • 與@name屬性，沒有@id不會做任何東西
     • 並與@name和@id不會停止。

• rich:column/@breakBefore

  現在breakRowBefore

• rich:page

  刪除。

• rich:layout

  刪除。

• rich:column/@sortOrder

  現在必須小寫。

• rich:dropDownMenu/@value

  現在rich:dropDownMenu/@label

• rich:dropDownMenu/@direction和rich:dropDownMenu/@jointPoint

  值這些已經從{top-left, top-right, bottom-left, bottom-right}和{tl, tr, bl, br}分別改爲{topLeft, topRight, bottomLeft, bottomRight}。

• rich:contextMenu/@submitMode，rich:dropDownMenu/@submitMode，rich:menuItem/@submitMode

  現在這些現在都rich:<whatever>/@mode，並且"none"需要的值更改爲"client"。

• rich:isUserInRole

  這只是停止工作，至少對我來說，有鑽嘴魚科08年2月2日和EL 2.2。幸運的是，EL 2.2不再需要它，可以使用request.isUserInRole(...)。

• rich:menuGroup/@value

  現在rich:menuGroup/@label。

• rich:tab/@label

  現在rich:tab/@header。

• rich:tab/f:facet/@name[.='label']

  現在rich:tab/f:facet/@name[.='header']。

• rich:tabPanel/@activeTabClass，rich:tabPanel/@contentStyle，rich:tabPanel/@disabledTabClass，rich:tabPanel/@inactiveTabClass，分別rich:tabPanel/@tabClass

  現在tabActiveHeaderClass，tabContentClass，tabDisabledHeaderClass，tabHeaderClass，tabInactiveHeaderClass，tabContentClass。

• rich:tree/@adviseNodeOpened

  這已被刪除，添加rich:treeNode/@expanded。這沒有很好的記錄：它必須是EL，例如"#{true}"，而不是"true"，並且它可以是是樹節點的bean屬性，例如， "#{node.expanded}"，或任何其他豆;必須是布爾值。 （同樣是新rich:collapsibleSubTable/@expanded屬性的真實。）

• rich:tree/@nodeFace

  現在rich:tree/@nodeType。

• rich:tree/@switchType

  現在rich:tree/@toggleType並可能rich:tree/@selectionType。

• rich:tree/@treeNodeVar

  現在var，或者可能只是刪除。

• rich:treeNodesAdaptor

  現在rich:treeModelAdaptor,並不再處理陣列，節點集，......或任何不Map或Iterable。它也失去了它的var屬性，就我所見，它完全用於嵌套使用。現在可用的唯一var屬性是祖先rich:tree的屬性。因此，例如，如果您想要同時使用父節點和當前子節點，則它們根本不可用。這種變化需要一個不重要的重寫或下面的kludge。

  OLD：

  <rich:tree> 
      <rich:treeNodesAdapter var="vm_host"> 
       <rich:treeNode .../> 
       <rich:treeNodesAdapter var="vm_guest"> 
        <rich:treeNode .../> 
       </rich:treeNodesAdapter> 
      </rich:treeNodesAdapter> 
  </rich:tree> 
  

  新：

  <rich:tree ... var="node"> <!-- Add a 'var' attribute --> 
      <rich:treeModelAdapter> 
       <c:set var="vm_host" value="#{node}"/> 
       <rich:treeNode .../> 
       <rich:treeModelAdapter> 
        <c:set var="vm_guest" value="#{node}"/> 
        <rich:treeNode .../> 
       </rich:treeModelAdapter> 
      </rich:treeModelAdapter> 
  </rich:tree> 
  

  你也可以使用<ui:param>代替<c:set>。

由於RichFaces拒絕錯誤檢查屬性名稱，轉換過程變得更加困難。您可以繼續使用舊名稱，但它們不起作用。