3

Mojarra 2.1.1 / Glassfish 3.1 で実行されているアプリがあり、現在 150,000 行以上のコードに成長しています。このアプリは、ViewScoped マネージド Bean と page-redirect-get パターン (つまり、faces-redirect=true) で ajax を広範囲に使用します。

常に私を悩ませていることの 1 つは、ページからページへ、および Bean から Bean へのパラメーターの受け渡しが明らかに容易でないことです (すべてのページには独自のバッキング Bean があります)。

フラッシュを機能させることができませんでした。通常、次のページの preRenderView イベント リスナーでフラッシュに書き込んだデータにアクセスする必要があります。これは、特にアプリケーションの再デプロイ後は確実に機能しません。

私は CDI を読み、JSF マネージド Bean から CDI Bean に移行しようと数日を費やしましたが、うまくいきません。Seam 3 と Glassfish 3.1 の間には多くの互換性の問題があるようです。Weld を 1.1.1 にアップグレードしましたが、これは役に立ちません。私の観点からすると、現時点では機能しません。たとえば、バッキング Bean の文字列に h:inputText を入力しようとしているページがありますが、これは機能しません。本当に単純なことです。

私が抱えているCDIの問題のため、非常に単純なテストアプリケーション（g/f 3.1でも）で必要なだけ実行するseam-faces @RenderScopedを使用できませんが、複雑なメインアプリケーションでは実行できません。

私が現在使用できる唯一の信頼できるメカニズムは、セキュリティ上の悪夢である URL パラメーターです。データへのアクセスが適切に認証されるようにあらゆる努力が払われていますが、何かが欠けているという変化が常にあり、ブラウザーで ...xhtml?id=51031 などを表示すると、他の ID を試すのをためらう人もいます。クリア テキストを回避し、名前と値のペアに意味のある名前を使用しないように、難読化コンバーターを作成しましたが、これでは問題の根本に到達しません。

ここで何かが欠けているのではないかと思いました.グラスフィッシュでも、他の誰もがこの問題に対して有効な解決策を持っていますか? 心配しすぎて、URL パラメーターに固執する必要がありますか? 他の提案はありますか？

ありがとう。

4

2 に答える 2

3

私は同じを見ました。私が試した時点では、Seam3 は非常にバグが多く、別のサーバーにデプロイするのは非常に困難でした。最初から問題なく動作するMyFaces CODIに切り替えました。あなたの場合、@ViewAccessScoped を見てください。これらの面倒な回避策をすべて取り除くことができます。

于 2011-08-21T19:26:57.603 に答える
2

設定する、または次のビューに渡すパラメーターを宣言します。

<f:metadata>
    <f:viewParam name="foo" value="#{bean.foo}" />
</f:metadata>

これは基本的bean.setFoo(request.getParameter("foo"))に、GET リクエストのモデル値の更新フェーズで行われます。

ナビゲーションの結果にパラメーターを追加すると、現在のビューのincludeViewParams=true時点で宣言されているパラメーターが<f:viewParam>次のビューに渡されます。

public String doSomething() {
    // ...
    return "next?faces-redirect=true&amp;includeViewParams=true";
}

(注:&amp;は重要です! は&XML に対応していないため機能しません)

次のビューは、<f:viewParam>それらを Bean に設定するために同じである必要があります。等々。

于 2011-06-18T19:57:53.747 に答える