JSF2.0以降のビュー定義言語として、JSPよりもFaceletsが推奨されるのはなぜですか？
JSF2.0以降、Faceletsビュー定義言語が優先ビュー定義言語であり、レガシーフォールバックとして非推奨となったJSPではないことがわかります。 JSF2.0以降のビュー定義言語として、FaceletsがJSPよりも好まれる理由を知りたいのですが？ JSPには、Faceletsを採用するための主な原動力となるテンプレート動作もあることは知っています。
PS：私は この投稿 をstackoverflowで経験しましたが、それが私の質問に答えるとは思いません。したがって、これを別の質問として投稿してください。
確かに、JSPにはsometemplating 機能がありますが、JSFでJSPを使用する最大の欠点は、JSPが次のように応答に書き込むことです。 JSFはテンプレートテキストコンテンツに出会うとすぐに、それを使用していくつかの前処理/後処理を行います。 JSF 1.0/1.1では、次のJSFコード
<h:outputText value="first"> second <h:outputText value="third"> fourth
作り出すだろう
2番目4番目1番目3番目
これは、JSF 1.0/1.1時代のa headache でした。開発者は、上記の例のsecondおよびfourthのようなテンプレートテキストを<f:verbatim>タグですべての場所にラップする必要があります。 JSF 1.2は、JSPを実行する代わりに解析する改善されたビューハンドラーでそれを解決しましたが、JSP構文がXMLのように「整形式」ではないため、内部はまだ非常に不格好でした。効率的なSAXベースのパーサーを使用できるように、XMLベースのビューテクノロジーが強く望まれていました。そしてFaceletsが生まれました（Ken Paulsenの "JSFTemplating"の中で）。
また、統合されたEL #{}をJSPテンプレートテキストで使用できなかったため、醜くなり、 nintuitive — ${}と#{}が混在するようになりました。また、JSTLはJSP上のJSF 1.xでは ビルド時間タグの表示 として使用できませんでした。また、<% %>を使用したJSP構文は古いものであり、Raw Javaコードを埋め込む可能性は 非常に悪い習慣 と見なされます） MVCイデオロギー 。
JSF/MVCの観点から見ると、JSPは単に醜くてひどいものであり、Faceletsは単純にクリーンで素晴らしいものです。
インターネットで以下の答えを見つけました。
JSPコンパイル時のオーバーヘッド
JSPページを編集、保存、再ロードするたびに、サーバーのJSPコンパイラはJavaサーブレットコードを生成し、それをサーブレットにコンパイルします。これは、JSP変換プロセスと呼ばれ、通常は1〜サーバーのパフォーマンスに応じて-2秒。
ファセットレットXMLコンパイル
JavaServer Pagesとは異なり、Faceletsページはサーブレットにコンパイルされません。 FaceletsページはXMLに準拠しているため、FaceletsフレームワークはSAXベースの高速コンパイラーを使用してビューを構築します。また、ページの変更をすぐに検出してレンダリングするようにFaceletsを構成できるため、JSF開発サイクルが高速化されます。
Ian Hlavats著の本「JSF 1.2コンポーネント」、49ページ ：
JSFアプリケーションの開発中は、JSFページに変更を加えることがよくあります。その結果、JSPページが頻繁に再コンパイルされ、このコンパイル時のオーバーヘッドが増大します。
Faceletsページは単純なXMLドキュメント（XHTMlページ）であり、サーブレットにコンパイルされることはなく、ビューのUIコンポーネントツリーを構築するSAXベースのコンパイルプロセスを使用します。したがって、JSP変換のオーバーヘッドがないため、FaceletsはJSPに比べて高速です。