4

私は現在、バージョン 3.3.3.Final から RichFaces 4 に移行したいプロジェクトに取り組んでいます。私は考えていた...

  • 移行前に考えたり、知ったり、考えたりするべき重要なことはありますか?

  • (ばかげた質問かもしれませんが...) richfaces 3 と richfaces 4 を「ミックス」できますか?

私が切り替えたい主な理由の 1 つは、richfaces 4 オートコンプリートを使用することです。richfaces 3 を使用してこのようなことを行う方法はありますか、それとも移行が最も簡単でしょうか?

私はJSFを使用しています。

4

2 に答える 2

8

TLDR: RichFaces は 2016 年 6 月に、十分に価値のある終焉を迎えました。

ここで、公式の移行ガイドは約 30% 完了していないことに注意してください。その指標として、移行ガイドに基づいて 2011 年に 378 行の XSLT スタイルシートを作成しました。その後、私は 2015 年 6 月までプロジェクトを中断し、さらなる調査と作業に基づいて、すでに 1090 行に達しています。どの XSLT スタイルシートにも、378/1090 = 約 35% のオーバーヘッドがあることに注意してください。

移行ガイドに記載されていることを行った後:

  1. 隣接するブラウザー タブで使用するコンポーネントごとに TLD/VLD で生成されたドキュメントをバージョンごとに 1 つずつ開き、慎重に比較します。属性の名前と目的には文書化されていない変更が多数あり、一部の属性は親コンテナーから子コンテナーに移動されています。

  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:regionstatus=

    2. 特定のウィジェットに適用する場合は、対応する属性status=を変更する必要があります。a4j:status/@id@name

    3. すべてを修正しても、まだ機能しません。

      • a4j:statuswith (削除された@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

    これは、少なくとも私にとっては、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}"not ) 、ツリー ノード (例: ) または他の Beanの Bean プロパティにする"true"ことができます。"#{node.expanded}"ブール値でなければなりません。(新しいrich:collapsibleSubTable/@expanded属性についても同様です。)

  • rich:tree/@nodeFace今rich:tree/@nodeType。

  • rich:tree/@switchType今rich:tree/@toggleType、そしておそらくrich:tree/@selectionType。

  • rich:tree/@treeNodeVarnow var、またはおそらく削除されたばかりです。

  • rich:treeNodesAdaptor

    現在は、配列、ノードセット、...、またはrich:treeModelAdaptor,または 以外のものを処理しなくなりました。また、その属性も失われており、私が見る限り、ネストされた使用のために完全に壊れています。現在使用できる属性は、祖先の属性のみです。たとえば、親ノードと現在の子ノードが同時に必要な場合、それらは単に利用できません。この変更には、重要な書き直し、または次のクラッジが伴います。MapIterablevarvarrich:tree

    年：

      <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 が属性名のエラーチェックを拒否しているため、変換プロセスはさらに困難になっています。古い名前を引き続き使用できますが、機能しません。静かに。

于 2015-06-26T04:30:51.793 に答える
6

移行前に考えたり、知ったり、考えたりするべき重要なことはありますか?

彼らの推奨事項は、独自のRichFaces 3.3.x - 4.x Migration Guideに従うことです。これは完全にはほど遠いようです。実際の経験については、以下の EJP の回答を参照してください。

(ばかげた質問かもしれませんが...) richfaces 3 と richfaces 4 を「ミックス」できますか?

いいえ、できません。それはそれ自体と衝突するでしょう。

于 2012-09-25T14:41:48.113 に答える