RichFaces 3 到 RichFaces 4 的迁移

Question

我目前正在处理一个项目，我想将其从 3.3.3.Final 版本迁移到 RichFaces 4。 我在想...

• 在迁移之前，我应该考虑、了解或考虑什么重要的事情吗？

• （可能是一个愚蠢的问题，但是...）你可以“混合”richfaces 3 和richfaces 4 吗？

我想要切换的主要原因之一是使用richfaces 4自动完成，有没有办法使用richfaces 3做这样的事情，或者迁移是最简单的？

我正在使用 JSF。

Answer 1

TLDR： RichFaces 于 2016 年 6 月走到了尽头。这是一个管理不善的灾难，不值得更好的项目。

请注意，官方迁移指南仅完成了大约 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 版之间进行如此重大的更改是另一个更深层次的谜团。 这是一个管理很差的产品。 我不会再迁移它，也不会重新部署它。

编辑我发现的未记录的更改（为简洁起见，使用 XPath 语法）：

• a4j:status

  1. 该文档在这一点上含糊不清，但for=属性已被删除：它现在默认在最近的父级a4j:region ，除非通过status=属性与特定小部件有联系。 因此，如果您在同一区域内有多个，它们现在都会触发。

  2. 如果您希望它通过status=应用于特定小部件，则必须将相应的a4j:status/@id更改为@name属性。

  3. 修复所有这些后，它仍然不起作用：

     • 带有@for （已删除）属性的a4j:status不会停止
     • 带有@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

  对于 Mojarra 2.2.08 和 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 var属性。 因此，例如，如果您同时想要父节点和当前子节点，它们根本不可用。 此更改需要进行非平凡的重写，或进行以下操作。

  老的：

   <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 拒绝对属性名称进行错误检查，转换过程变得更加困难。 您可以继续使用旧名称，但它们不起作用。

Answer 2

在迁移之前，我应该考虑、了解或考虑什么重要的事情吗？

他们的建议是遵循他们自己的RichFaces 3.3.x - 4.x 迁移指南——这似乎还远未完成，请参阅下面 EJP 的回答以获得真实体验。

---

（可能是一个愚蠢的问题，但是...）你可以“混合”richfaces 3 和richfaces 4 吗？

不，你不能。 它会与自己发生冲突。