私は現在JSFを学んでおり、<h:form>
を使用するときはいつも、JSFの標準的な動作は常にpreviouscurrentページのURLとは対照的に、ブラウザのページ。
これは、JSFが常に同じページにフォームを投稿し、コントローラーがページの場所が変更されたことを知らないブラウザーに返すページをレンダリングする方法に関係していることを理解しています。
JSFは、これに対処するためのクリーンで堅実な方法がなければならないほど長い間存在しているようです。もしそうなら、共有してくれませんか?
さまざまな回避策を見つけましたが、悲しいことに、本当の確実な解決策とは思えないものはありません。
"?faces-redirect=true"
をeveryBeanのアクションの戻り値に追加してから、@RequestScoped
を他のもの(Flashスコープ、CDI会話、@ SessionScopedなど)で置き換える方法を見つけてください。"?faces-redirect=true"
の品質が優れている場合、すべての要求をこのように処理するようにアプリケーション全体を構成する方法はありますか?
実際、JSFは、フォームベースのアプリケーションをターゲットとしたMVCフレームワークとして、POSTフォームを、_<h:form>
_のページがリクエストされたフォームと同じURLに送信します。確認できます。生成されたHTML出力の_<form action>
_ URLを確認することにより、これはpostbackとして特徴付けられるWeb開発用語です。ポストバックのナビゲーションはデフォルトでは、新しいURLへの新しいリクエストは発生しませんが、代わりに、ターゲットページを応答のコンテンツとしてロードします。
一般に、ナビゲーション/リダイレクトに関する適切なアプローチは、ビジネス要件とリクエストの idempotence (読み取り:「ブックマーク可能性」)に依存します(注:具体的なコード例については、「参照」リンクを参照してください以下)。
リクエストがべき等である場合は、POSTフォームの代わりにGETフォーム/リンクを使用します(つまり、_<a>
_、_<form>
_、_<h:link>
_または_<h:button>
_ _<h:form>
_および_<h:commandXxx>
_)の代わりに。
たとえば、ページ間のナビゲーション、Googleのような検索フォームなど。
リクエストがべき等でない場合、結果を同じビューで条件付きで表示します(つまり、アクションメソッドからnull
またはvoid
を返し、<h:message(s)>
などを使用します。 rendered
)。
たとえば、ページ内のデータ入力/編集、マルチステップウィザード、モーダルダイアログ、確認フォームなど。
リクエストが-等ではないが、ターゲットページがi等である場合は、POSTの後にリダイレクトを送信します(つまり、アクションメソッドから_?faces-redirect=true
_で結果を返すか、ExternalContext#redirect()
、または従来のXMLナビゲーションの場合は_<redirect/>
_と入力します)。
たとえば、編集の成功後にすべてのデータのリストを表示したり、ログイン後にリダイレクトしたりなど。
通常、純粋なページ間ナビゲーションはi等であり、これは多くのJSFスターターがコマンドリンク/ボタンを悪用して失敗し、その後URLが変更されないと文句を言うことに注意してください。また、SEO/UXに関して開発された実世界のアプリケーションでは、ナビゲーションケースが使用されることはほとんどないことに注意してください。
また、POSTを使用することは、リクエストパラメータがURLですぐに表示されないため、GETよりも「安全」ではありません。HTTPリクエスト本文で表示され、操作可能です。優先する理由はありませんPOST「セキュリティ」のためのべき等の要求。実際のセキュリティは、HTTPの代わりにHTTPSを使用し、現在ログインしているユーザーがエンティティXのクエリ、またはエンティティXの操作など。適切なセキュリティフレームワークがこのための注釈を提供します。