ジャカルタの顔

Jakarta Faces（旧称Jakarta Server FacesおよびJavaServer Faces ( JSF )）は、Web アプリケーション用のコンポーネントベースのユーザーインターフェイスを構築するためのJava仕様です。^[2]これは、Java コミュニティプロセスを通じて、 Java Platform, Enterprise Editionの一部として標準として公式化されました。これは、ページ内で再利用可能な UI コンポーネントを使用することで、サーバーベースのアプリケーションのユーザーインターフェイス(UI)の構築を簡素化するMVC Web フレームワークです。^[3]

JSF 2.xは、デフォルトのテンプレートシステムとしてFaceletsを使用します。ソフトウェアのユーザーは、XULまたはJavaを使用することもできます。^{[4] JSF 1.xは、デフォルトのテンプレートシステムとして}JavaServer Pages (JSP)を使用します。

2001年、最終的にJavaServer Facesとなった技術のオリジナルのJava仕様要求（JSR）では、 javax.servlet.ui^{[5]という名前のパッケージの開発が提案されました。}

2001年6月、JavaWorldはエイミー・ファウラーのチームが「Webベースのユーザーインターフェースを作成するためのアプリケーションフレームワーク」として設計した「JavaServer Faces API」（別名「Moonwalk」）について報告した。^[6]

Facelets（Java Server Faces専用に設計）は、JSF 2.0の公式ビュー技術として採用されました。これにより、JSPに存在していたライフサイクルの競合が解消され、Java開発者は回避策を講じる必要がなくなりました。^[7]

新しい JSF 開発では、、などのJava アノテーションへの幅広いアクセスも提供されるため、フレームワーク拡張を除くすべてのケースでが不要になります。ナビゲーションも簡素化され、ナビゲーション ケースが不要になります。ページ遷移は、目的の View または Facelet の名前を渡すだけで呼び出すことができます。 @ManagedBean@ManagedProperty@FacesComponentfaces-config.xml,faces-config.xml

部分的な状態の保存とドキュメント オブジェクト モデル (DOM) の更新の追加は、組み込みの標準化されたAJAXサポートの一部です。

最新の JSF リリースには、画像、CSS、Javascript などのリソースを処理するためのサポートが組み込まれており、成果物をコンポーネント ライブラリに含めたり、JAR ファイルに分離したり、Web アプリケーション内の一貫した場所に単純に配置したりすることができます。これには、リソースの論理的な命名とバージョン管理が含まれます。

JSF 2.0 には、 Ruby on RailsRAILS_ENVと同様に、イベントのサポートの追加、開発、ステージング、および本番環境の個別のモードの追加、標準コンポーネント セットの大幅な拡張など、その他の多くの変更も含まれています。

• JSF 4.0 (2022-05-15) – 主な機能: 非推奨のもの (ネイティブ管理 Bean、ネイティブ EL 参照) を削除、デフォルトでは拡張ビューなし、ClientWindowScoped を追加
• JSF 3.0.0 (2020-10-28) – パッケージ名が Javax から Jakarta に変更されました。
• JSF 2.3 (2019-09-10) – Jakarta EE 用の Jakarta Server Pages API の最初のリリース。API も動作も変更されていません。
• JSF 2.3 (2017-03-28) – 主な機能: 検索式、拡張子のないURL、完全なクラスのBean検証、WebSocketを使用したプッシュ通信、CDIとの統合の強化。^[8]
• JSF 2.2 (2013-05-21) – ステートレスビュー、ページフロー、ポータブルリソースコントラクトの作成機能などの新しい概念が導入されました。^[9]
• JSF 2.1 (2010-11-22) – JSF 2.0のメンテナンスリリース2。仕様変更はごくわずか。^{[10] [11]}
• JSF 2.0 (2009-07-01) – 使いやすさ、機能強化、パフォーマンス向上のためのメジャー リリース。Java EE 6 と同時にリリースされます。
• JSF 1.2 (2006-05-11) – コア システムと API に多くの改善が加えられました。Java EE 5 と同時にリリースされました。Java EE への最初の採用です。
• JSF 1.1 (2004-05-27) – バグ修正リリース。仕様の変更はありません。
• JSF 1.0 (2004-03-11) – 最初の仕様がリリースされました。

コンポーネント駆動型UI設計モデルに基づいて、JavaServer Faces はビュー テンプレートまたはFaceletsビューと呼ばれる XML ファイルを使用します。FacesServletリクエストを処理し、適切なビュー テンプレートをロードし、コンポーネント ツリーを構築し、イベントを処理し、クライアントに応答 (通常は HTML 言語) をレンダリングします。UI コンポーネントとスコープ対象のその他のオブジェクトの状態は、各リクエストの最後にstateSaving (注:一時的に true ) と呼ばれるプロセスに保存され、そのビューが次に作成されるときに復元されます。オブジェクトと状態は、クライアント側でもサーバー側でも保存できます。

JSFは、リッチインターネットアプリケーション開発技術であるAJAXと組み合わせて使用​​されることが多い。AJAXは、リッチなユーザーインターフェースの作成を可能にするWeb開発技術と技術の組み合わせである。Mojarra （JSFリファレンス実装^[13]）とApache MyFacesのユーザーインターフェースコンポーネントは、もともとHTML専用に開発されており、AJAXはJavaScript経由で追加する必要がありました。しかし、これは次のように変更されました。

JSF は複数の出力形式をサポートしているため、AJAX対応コンポーネントを簡単に追加して、JSF で作成されたユーザー インターフェイスを改良できます。JSF 2.0 仕様では、AJAX 要求ライフサイクルを標準化し、AJAX イベントへのシンプルな開発インターフェイスを提供することで、AJAX の組み込みサポートを提供しています。この仕様により、クライアントによってトリガーされたイベントは、検証、変換、メソッド呼び出しを経てから、XML DOM 更新を介してブラウザーに結果を返すことができます。

JSF 2 には、ブラウザで JavaScriptが無効になっている場合のGraceful Degradationのサポートが含まれています。

次の企業およびプロジェクトは、AJAX ベースの JSF フレームワークまたはコンポーネント ライブラリを提供しています。

• Apache MyFaces – AJAX コンポーネントを使用したApache Foundation JSF 実装
• Backbase Enterprise AJAX – JSF エディション– AJAX フレームワーク
• BootsFaces Bootstrap をベースにしたオープンソースの JSF フレームワーク
• IBM ノート– XPages
• ICEfaces – オープンソース、Java JSF 拡張フレームワークと豊富なコンポーネント、JavaScript なしの AJAX
• JBoss RichFaces ( AJAX4jsfから派生し、これを置き換えます) – レイアウト、ファイルのアップロード、フォーム、入力、その他多くの機能のための AJAX 対応 JSF コンポーネント。2016 年 6 月にサポートが終了しました。
• OmniFaces – オープンソースの JSF ユーティリティ ライブラリ
• OpenFaces – JSF コンポーネントを備えた AJAX フレームワーク
• Oracle ADF Faces リッチ クライアント– Oracle アプリケーション開発フレームワーク
• PrimeFaces – JSF コンポーネントを備えた AJAX フレームワーク
• Sun Java BluePrints AJAX コンポーネント
• ZK – JSF コンポーネントを備えた AJAX フレームワーク

ThoughtWorksは2014年1月のTechnology Radar誌で次のように書いている。^[14]

JSF (JavaServer Faces) の使用でチームがトラブルに遭遇するケースが引き続き見られるため、このテクノロジを避けることを推奨します。チームは、プログラミング モデルが自分たちに適しているかどうかを実際に評価することなく、JEE 標準であるという理由で JSF を選択しているようです。JSF はHTML、CSS、HTTP を抽象化しようとするため、現代のWeb フレームワークとは正反対であり、欠陥があると考えられます。ASP.NET Web フォームと同様に、JSF はステートレス プロトコル HTTP の上にステートフル性を作成しようとしますが、共有サーバー側状態に関連するさまざまな問題を引き起こします。JSF 2.0 での改善点は認識していますが、このモデルは根本的に破綻していると考えます。チームにはシンプルなフレームワークを使用し、HTTP、HTML、CSS などの Web テクノロジを採用して理解することをお勧めします。

2014 年 2 月、Çağatay Çivici (PrimeFaces リーダー) は、ThoughtWorks の批判に対して、「JSF はもはや言われてきたものではない」というタイトルの投稿で返答しました。Çivici は、長年にわたる JSF の改良により、最新の Web 開発を取り入れた多くの機能が提供され、独自の JavaScript、HTML、CSS を記述するオプションが提供されていると主張しています。また、状態に関して、Çivici は次のように書いています。^[15]

JSF は本質的にステートフル フレームワークであり、ステートにより Web アプリケーションの開発が容易になります。JSF 2.0 以降で導入された改善されたステート管理手法 (ステートレス モード、部分的なステート保存など) により、JSF も拡張可能になりました。

2014年11月にDZoneウェブサイトに掲載された「なぜJSFを避けるべきか」という記事の中で、Jens Schauderは次のように書いている。^[16]

JSF の推奨プレゼンテーション テクノロジである Facelets は、一見すると、古き良き JSP や Thymeleaf のような通常のテンプレート テクノロジのように見えます。しかし、よく見ると、その恐ろしさが明らかになります。HTML を構造化するのと同じ場所に、アクションで UI のどの部分を更新するかというロジックも配置します。これは、私の考えでは、関心の分離の原則に明らかに違反しています。さらに良いのは、サーバー側のライフ サイクルを変更する即時属性です。さらに、これだけでは不十分な場合は、使用するタグに応じてさまざまな方法で変更が行われます。このようなことは作り話ではあり得ません。

2016年2月、エンタープライズJavaコミュニティウェブサイトTheServerSideは、 JSFの使用は最終製品の品質を損なう可能性があるため、使用しないことを推奨する記事を公開しました。記事では、5つの理由について詳しく説明しています。^[17]

1. 単純な作業が難しくなる;
2. JSF には柔軟性が欠けています。
3. 学習曲線は急峻です。
4. 標準Javaテクノロジーとの非互換性。
5. 基本的な AJAX サポート。

ウィキメディア・コモンズには、 Jakarta Facesに関連するメディアがあります。

• 公式サイト