Java Server Faces 2.0 の主な欠点は何ですか?

https://stackoverflow.com/questions/3623911

26-09-2019
|

質問

昨日、私は現在、幸せな ASP.NET MVC / jQuery 開発者であるにもかかわらず、Java Server Faces 2.0 に関するプレゼンテーションを見て、本当に印象的でした。JSF で最も気に入ったのは、大量の AJAX 対応 UI コンポーネントで、特に AJAX を多用するサイトで、ASP.NET MVC よりもはるかに高速に開発できるようです。統合テストも非常に素晴らしく見えました。

JSFのメリットばかりを強調したプレゼンテーションだったので、その裏側についてもお聞きしたいです。

そこで私の質問は次のとおりです。

Java Server Faces 2.0 の主な欠点は何ですか?
JSF 開発者が JSF の代わりに ASP.NET MVC の使用を検討する理由は何でしょうか?

解決

JSF 2.0 の欠点?正直なところ、しっかりとした背景知識がない場合は、比較的急な学習曲線は別として、基本的な Web 開発 (HTML/CSS/JS、サーバー側とクライアント側など) 基本的な Java サーブレット API (リクエスト/レスポンス/セッション、転送/リダイレクトなど)、重大なデメリットは思いつきません。現在のリリースの JSF は、初期の頃に得た否定的なイメージを取り除く必要があり、その間にいくつかの重大な欠点がありました。

JSF 1.0 (2004 年 3 月)

これが最初のリリースでした。コア領域とパフォーマンス領域の両方に、知られたくないバグが散乱していました。Web アプリケーションは、常に直感的に期待したとおりに動作するとは限りません。開発者なら泣きながら逃げ出すでしょう。

JSF 1.1 (2004 年 5 月)

これはバグ修正リリースでした。パフォーマンスはまだあまり向上していませんでした。大きな欠点も 1 つありました。JSF ページに HTML を完璧にインライン化することはできません。すべてのプレーンバニラ HTML がレンダリングされます前に JSF コンポーネントツリー。プレーンバニラをすべて包む必要があります <f:verbatim> タグを使用して、JSF コンポーネントツリーに含まれるようにします。これは仕様どおりではありましたが、多くの批判を受けました。「a.o」も参照してください。 JSF/ファセット:JSF/Facelet と HTML タグを混在させることがなぜ良くないのでしょうか?

JSF 1.2 (2006 年 5 月)

これは、Ryan Lubke が率いる新しい JSF 開発チームの最初のリリースでした。新しいチームはたくさんの素晴らしい仕事をしてくれました。仕様にも変更がありました。主な変更点はビュー処理の改善です。これにより、JSF が JSP から完全に分離されるため、JSP とは異なるビューテクノロジを使用できるだけでなく、開発者が面倒な処理を行わずにプレーンなバニラ HTML を JSF ページにインライン化できるようになります。 <f:verbatim> タグ。新チームのもう一つの主な焦点はパフォーマンスの向上でした。Sun JSF Reference Implementation 1.2 (コード名は モハラ 2008 年頃のビルド 1.2_08 以降)、事実上すべてのビルドには、通常の (マイナーな) バグ修正に加えて (大幅な) パフォーマンスの改善が施されて出荷されました。

JSF 1.x (1.2 を含む) の唯一の重大な欠点は、 リクエスト そして セッション スコープ、いわゆる会話範囲。このため、開発者は、検証、変換、モデル変更、およびアクション呼び出しをより適切に処理するために、後続のリクエストで初期モデルデータを保持したい場合は常に、非表示の入力要素、不必要な DB クエリ、および/またはセッションスコープの悪用に苦労する必要がありました。複雑な Web アプリケーション。この問題は、次のような後続のリクエストで必要なデータを保持するサードパーティライブラリを採用することで軽減される可能性があります。 MyFaces トマホーク <t:saveState> 成分、 JBoss シーム会話範囲とマイフェイセス・オーケストラ会話の枠組み。

HTML/CSS 純粋主義者にとってのもう 1 つの欠点は、JSF がコロンを使用することです。 : HTML 要素の一意性を確保するための ID 区切り文字として使用 id 特にコンポーネントがビュー内で複数回再利用される場合 (テンプレート化、コンポーネントの反復など)、生成された HTML 出力内で。これは CSS 識別子では無効な文字であるため、 \ CSS セレクターでコロンをエスケープすると、次のような醜くて奇妙に見えるセレクターが生成されます。 #formId\:fieldId {} あるいは #formId\3A fieldId {}. 。こちらも参照 CSS セレクターでコロン「:」を含む JSF 生成の HTML 要素 ID を使用するにはどうすればよいですか? ただし、純粋主義者ではない場合は、こちらもお読みくださいデフォルトでは、JSF は Web 標準の CSS 部分と互換性のない使用できない ID を生成します。.

また、JSF 1.x には、そのままの状態で Ajax 機能が付属していませんでした。実際には技術的な欠点ではありませんが、この時期の Web 2.0 の誇大宣伝により、機能的な欠点になりました。エクサデル Ajax4jsf をいち早く導入しました。これは長年にわたって徹底的に開発され、 JBoss リッチフェイスコンポーネントライブラリ。別のコンポーネントライブラリにも Ajax 機能が組み込まれて出荷されており、よく知られているものは次のとおりです。 ICEフェイス.

JSF 1.2 のライフタイムの約半分で、新しい XML ベースのビューテクノロジが導入されました。ファスレット. 。これにより、特にテンプレートの領域において、JSP よりも大きな利点が得られました。

JSF 2.0 (2009 年 6 月)

これは、Ajax がバズワードとなった 2 番目のメジャーリリースでした。多くの技術的および機能的な変更がありました。JSP はデフォルトのビューテクノロジーとして Facelets に置き換えられ、Facelets は純粋な XML (いわゆる XML) を使用してカスタムコンポーネントを作成する機能を追加して拡張されました。複合コンポーネント）。こちらも参照 JSF2.0 以降のビュー定義言語として、JSP よりも Facelets が好まれるのはなぜですか?

Ajax パワーは、 <f:ajax> Ajax4jsf と多くの類似点があるコンポーネント。アノテーションと設定よりも規約の拡張機能が導入されました。殺す冗長な faces-config.xml できるだけファイル化してください。また、デフォルトの命名コンテナ ID 区切り文字 : が構成可能になったので、HTML/CSS の純粋主義者も安心できました。次のように定義するだけです。 init-param で web.xml 名前と一緒に javax.faces.SEPARATOR_CHAR そして、クライアント ID のどこにもそのキャラクターを自分で使用していないことを確認してください。 -.

最後になりましたが、新しいスコープが導入されました。 ビュー 範囲。これにより、前述したもう 1 つの大きな JSF 1.x の欠点が解消されました。Bean を宣言するだけです @ViewScoped 後続の (会話) リクエストでデータを保持するためのあらゆる方法に手間をかけることなく、会話スコープを有効にします。あ @ViewScoped Bean は、同期的または非同期 (Ajax) のいずれかで、送信して同じビューに (開いているブラウザーのタブ/ウィンドウとは無関係に!) 移動している限り存続します。こちらも参照マネージド Bean の View スコープと Request スコープの違いそして適切な Bean スコープを選択するにはどうすればよいですか?

実際には JSF 1.x の欠点はすべて解消されましたが、重大な問題となる可能性のある JSF 2.0 固有のバグが存在します。の @ViewScoped タグハンドラーで失敗する部分的な状態保存における鶏が先か卵が先かの問題が原因です。これは JSF 2.2 で修正され、Mojarra 2.1.18 でバックポートされました。また HTML5 のようなカスタム属性を渡す data-xxx はサポートされていません。この問題は、JSF 2.2 の新しいパススルー要素/属性機能によって修正されています。さらに、JSF 実装 Mojarra には、独自の問題セット. 。それらの比較的多くは、時々直感的ではない動作が起こる <ui:repeat>, 、新しい部分的な状態保存の実装そしてそのフラッシュスコープの実装が不十分. 。それらのほとんどは Mojarra 2.2.x バージョンで修正されています。

JSF2.0の頃、プライムフェイス jQuery と jQuery UI に基づいて導入されました。これは最も人気のある JSF コンポーネントライブラリになりました。

JSF 2.2 (2013 年 5 月)

JSF 2.2 の導入により、HTML5 は古いすべての JSF バージョンで技術的にサポートされていたにもかかわらず、バズワードとして使用されました。こちらも参照 JavaServer Faces 2.2 と HTML5 のサポート、なぜ XHTML がまだ使用されているのか. 。最も重要な JSF 2.2 の新機能は、カスタムコンポーネント属性のサポートであり、これにより次のような可能性の世界が開かれます。カスタムテーブルレスラジオボタングループ.

実装固有のバグや、バリデーター/コンバーターで EJB を挿入できない (JSF 2.3 ですでに修正されている) などのいくつかの「迷惑な小さなこと」を除けば、JSF 2.2 仕様には大きな欠点はありません。

コンポーネントベースの MVC とリクエストベースの MVC

JSF の主な欠点は、生成された HTML/CSS/JS に対するきめ細かい制御がほとんどできないことだと考える人もいるかもしれません。それは JSF 独自のものではありません。 コンポーネントベース MVC フレームワークではなく、 リクエスト（アクション）ベース MVC フレームワーク。MVC フレームワークを検討する際に、HTML/CSS/JS の高度な制御が主な要件である場合は、すでにコンポーネントベースの MVC フレームワークではなく、次のようなリクエストベースの MVC フレームワークを検討する必要があります。春のMVC. 。HTML/CSS/JS 定型文はすべて自分で作成する必要があることだけを考慮する必要があります。こちらも参照リクエストMVCとコンポーネントMVCの違い.

以下も参照してください。

JSF、サーブレット、JSP の違いは何ですか? （基本を理解するためだけに）
JSF を使用したテーブルレス CSS レイアウトの開発 (JSF に関する別の迷信)
JSF とプレーンな HTML/CSS/JS/jQuery の比較 (JSF が間違った選択の場合)
Web アプリケーションのデザインパターン (MVC の背後にあるイデオロギーを示しています)

他のヒント

JSF で 5 年間働いてきたので、あと 2 セント追加できると思います。

二 メジャーJSF 欠点:

大きな学習曲線。JSF は複雑です、それはまさに真実です。
その成分自然。コンポーネントベースのフレームワークは、膨大な量の複雑さや災害 (約 5 年以内に JSF での GET がサポートされないなど) を伴う Web の本質を隠そうとします。
私の意見では、HTTP リクエスト/レスポンスを開発者から隠すのは大きな間違いです。私の経験から言えば、コンポーネントベースのフレームワークはすべて Web 開発に抽象化を追加しますが、その抽象化により不必要なオーバーヘッドが発生し、複雑さが増します。

そして マイナー 私の頭に浮かぶ欠点：

デフォルトでは、オブジェクトの ID はその親の ID で構成されます (例: form1:button1)。
間違ったページの断片をコメントアウトする簡単な方法はありません。鬼ごっこ <ui:remove> とにかく解析される構文的に正しいコンテンツが必要です。
低品質のサードパーティ製コンポーネント。チェックしないでください isRendered() 内部 processXxx() 続行する前に方法を選択してください。
LESSと煎茶を取り入れるのは難しいです。
REST とはうまく連携できません。
すぐに使用できるコンポーネントには独自の CSS スタイルがあり、上書きする必要があるため、UX デザイナーにとってはそれほど簡単ではありません。

誤解しないでください。バージョン 2 の JSF はコンポーネントフレームワークとしては非常に優れていますが、依然としてコンポーネントベースであり、今後もコンポーネントベースです...

Tapestry、Wicket の人気の低さと、経験豊富な JSF 開発者の熱意の低さを見てください (さらに意味のあることです)。対照的に、Rails、Grails、Django、Play! の成功を見てください。フレームワーク - それらはすべてアクションベースであり、プログラマーから隠そうとしません。 真のリクエスト/レスポンス そして 無国籍な性質 ウェブの。

私にとって、それは JSF の大きな欠点です。私見では、JSF は、ある種のアプリケーション (イントラネット、フォーム集約型) には適していますが、実際のアプリケーションには適しています。 ウェブ アプリケーションでは、それは良い方法ではありません。

フロントエンドに関する誰かの選択に役立つことを願っています。

思い浮かぶいくつかの欠点:

JSF はコンポーネントベースのフレームワークです。これには、コンポーネントモデルに従うことに関係する固有の制限があります。
AFAIK JSFは投稿のみをサポートしているため、どこかに入手したい場合は、プレーンサーブレット/JSPを実行する必要があります。
ほとんどのコンポーネントは、リレーショナルデータベースやフロントエンドJavaScriptなどのドメインを介して抽象化を提供しようとします。これらの抽象化は「漏れやすい」もので、デバッグが非常に困難です。
これらの抽象化は、若手開発者や特定のドメインに慣れていない人にとって良い出発点になる可能性があります (例:フロントエンド JavaScript) が含まれますが、複数のレイヤーが関係しており、それらを使用するほとんどの人は内部で何が起こっているのかほとんど理解していないため、パフォーマンスを最適化するのは非常に困難です。
JSF で通常使用されるテンプレートメカニズムは、Web デザイナーの動作とは何の関係もありません。JSF の WYSIWYG エディタは原始的であり、いずれにせよ、デザイナーが提供する HTML/CSS を変換するには長い時間を費やす必要があります。
EL 式のようなものは静的にチェックされず、コンパイラーと IDE の両方がエラーを見つけるのにうまく機能していないため、実行時にキャッチする必要があるエラーが発生します。Ruby や PHP のような動的に型付けされる言語ではこれで問題ないかもしれませんが、Java エコシステムの巨大な肥大化に耐えなければならない場合は、テンプレートの型付けが必要になります。

総括する： JSF で節約できる時間は、JSP/サーブレット/Bean 定型コードの作成を避けることで、その 10 倍をスケーリングして希望どおりに実行するために費やすことになります。

私にとって、JSF 2.0 の最大の欠点は、JSF だけでなく、有益な作業を行うために使用しなければならないコンポーネントライブラリの学習にも時間がかかることです。本当に熟練するためには、膨大な数の仕様や標準に対処する必要があることを考えてください。

さまざまな形式の HTML。それを知る必要がないふりをしないでください。
HTTP -- 何が起こっているのか分からないときは、Firebug を開いて確認する必要があります。そのためにはこれを知る必要があります。
CSS -- 好むと好まざるにかかわらず。実際にはそれほど悪くはありませんし、少なくともいくつかの優れたツールが存在します。
XML -- これほどまでに名前空間を使用するのは、おそらく JSF が最初でしょう。
サーブレット仕様。遅かれ早かれ、このパッケージのメソッドを呼び出すことになるでしょう。それとは別に、Facelet がどのように XHTML などに変換されるかを知る必要があります。
JSP (主に、JSF で JSP が必要ない理由を理解するため)
JSTL (繰り返しますが、主にレガシーフレームワークに対処するため)
さまざまな形式の式言語 (EL)。
ECMAScript、JavaScript、その他任意の名前を呼び出すことができます。
JSON -- 使用しない場合でも、これは知っておく必要があります。
アヤックス。JSF 2.0 はこれをうまく隠していると思いますが、それでも何が起こっているのかを知る必要があります。
ドム。そしてブラウザがそれをどのように使用するか。ECMAScript を参照してください。
DOM イベント -- それ自体がトピックです。
Java Persistence Architecture (JPA) は、アプリにバックエンドデータベースを持たせたい場合に使用します。
Javaそのもの。
ついでにJSEEも。
Context dependency Injection 仕様 (CDI) と、それが JSF 2.0 とどのように衝突し、どのように使用されるか
JQuery -- JQuery なしでもやっていけることを望みます。

ここで、それが完了したら、独自の仕様、つまり、途中で選択するコンポーネントライブラリとプロバイダライブラリを使用することができます。

PrimeFaces (私が選んだコンポーネントライブラリ)
リッチフェイス
マイフェイス
ICE顔
EclipseLink (私のJPAプロバイダー)
休止状態
溶接

そして容器も忘れずに！これらすべての構成ファイルは次のとおりです。

GlassFish (2、3 など)
ジェイボス
トムキャット

それで -- これで簡単になりましたか?確かに、最も単純な対話を備えた最も基本的な Web ページを実行したいだけである限り、JSF 2.0 は「簡単」です。

簡単に言えば、JSF 2.0 は、今日のソフトウェア界に存在するテクノロジを貼り合わせたものの中で最も複雑で扱いにくいものです。そして、それ以外に使いたいものが思いつきません。

通常、経験の浅い開発者が作成するアプリケーションは非常に遅く、コードは非常に醜く、保守が困難になります。一見簡単に始めることができますが、実際には、優れたプログラムを作成したい場合は、学習にある程度の投資が必要です。
少なくとも最初は、何らかの問題で「立ち往生」することが多く、実際に作業するよりも、インターネット上の balusc の投稿を読むことに多くの時間を費やします :) しばらくすると、そのようなことはどんどん少なくなりますが、それでも迷惑になる可能性があります。
問題が自分の知識不足や間違いによるものではなく、実際にはバグであることが判明すると、さらに面倒になります。Mojarra は非常にバグが多く、別のコンポーネント層がさらに問題を追加しました。Richfaces はこれまでに書かれた中で最大のクソソフトウェアでした :) それがバージョン 4 でどうなっているのかはわかりません。より優れた Primefaces がありますが、それでも、特によりエキゾチックなコンポーネントを使用すると、バグや機能の欠如に遭遇する可能性があります。そして、Primefaces のアップデートには料金を支払う必要があります。つまり、バグが多いと言えますが、特に 2.2 バージョンで仕様上のいくつかの問題が修正されてからは改善されています。フレームワークはより成熟してきていますが、まだ完璧には程遠いです (myfaces のほうが良いかも?)。
特に柔軟性があるとは思えません。非常にカスタマイズされたものが必要で、それを行うコンポーネントがない場合は、少し面倒になることがよくあります。繰り返しますが、私は平均的な開発者の観点から話しています - 締め切りがあり、チュートリアルをざっと読んだり、実際にどのように機能するかを学ぶ時間がなくて行き詰まったときにスタックオーバーフローを検索したりするものです:) 多くの場合、一部のコンポーネントには必要なものが「ほぼ」含まれているように見えますが、正確にはそうではなく、場合によっては、必要なことを実行するのに時間がかかりすぎる可能性があります:) 独自のコンポーネントを作成する方が良いのか、それとも既存のコンポーネントを使用する方が良いのかを判断する際には注意が必要です。実際、本当にユニークなものを作成している場合は、JSF はお勧めしません。

つまり、私の欠点は次のとおりです。複雑さ、開発の進行があまりスムーズではない、バグが多く、柔軟性に欠ける。

もちろんメリットもありますが、それはあなたの質問ではありません。とにかく、これはフレームワークに関する私の経験であり、他の人は異なる意見を持っているかもしれないので、最善の方法は、しばらく試して、それが自分に合うかどうかを確認することです（単純なものではなく、より複雑なものです。JSFはそこで本当に威力を発揮します:） JSF は CRM などのビジネスアプリケーションです。

「あなたはコントローラのコードに行かなくても制御または変更することができないというJSF意志出力ビュー層のHTMLとJavaScript。」の

実際にJSFはあなたに柔軟性を与え、あなたは、標準/サードパーティのコンポーネントを使用するか、レンダリングされているものを完全に制御を持っている独自に作成することができます。それはちょうどあなたがJSF 2.0を使用してカスタムコンポーネントを作成する必要がxhtmlの一つです。

JSF を使用してサンプルプロジェクトを開発しました (3 週間の調査だったので、いくつかの点が失われている可能性があります)。

コア JSF を使用するようにし、コンポーネントが必要な場合は PrimeFaces を使用します。

このプロジェクトはナビゲーション付きの Web サイトでした。メニューをクリックすると、各ページが ajax 経由でロードされる必要があります。

このサイトには 2 つの使用例があります。

グリッドのあるページ。グリッドは ajax 経由でロードされ、ソートとページングをサポートする必要があります。
3 ステップのウィザードページ。各ページには、クライアント側の検証 (単純な検証の場合) とサーバー側の Ajax ベースの検証 (複雑な検証の場合) があります。サーバー例外 (サービス層から) は、次のページに移動せずに、ウィザードの同じページに表示される必要があります。

次のことがわかりました。

JSF ビューステートを修正するには、omniFaces のハックをいくつか使用する必要があります。ajax 経由でページを相互に含めると、JSF 状態が破損します。これは JSF のバグのようで、次のリリースでは修正される可能性があります (2.3 では修正されません)。
JSF フローが ajax で正しく動作しません (または、動作させることができませんでした!) 代わりに primeface ウィザードコンポーネントを使用しようとしますが、クライアント検証はサポートされていないようで、標準の JSF フロー標準ではないため意味がありません。
jqGird などの jQuery コンポーネントを使用し、JSON 結果をロードする必要がある場合は、純粋なサーブレットを使用することをお勧めします。JSF は何もしません。したがって、この種のコンポーネントを使用すると、設計は JSF に適合しなくなります。
ajax が完了すると、いくつかのクライアントスクリプトを実行しようとします。 ajaxComplete そして、PF 4 が独自の ajax イベントを実装していることがわかりました。いくつかの jQuery コンポーネントがあったため、コードを変更する必要があります。

上記のサンプルを次のように変更すると、 非 Ajax プロジェクト (または少なくとも ajax プロジェクト以外) では、上記の問題の多くは発生しません。

私たちの研究を次のように要約します。

JSF は、完全に Ajax ベースの Web サイトではうまく機能しません。

もちろん、JSF にはプロジェクトによっては非常に役立つ優れた機能がたくさんあるので、プロジェクトのニーズを考慮してください。

JSF の利点を確認するには、JSF 技術文書を参照してください。私の意見では、JSF の最大の利点は、@BalusC からの完全かつ膨大なサポートです ;-)

私は、Java Serverはすべての専門家を顔ではありませんよ。しかし、私見では主な欠点は、それがサーバ側であるということです。私は学習とレールのフレームワーク上のASP.NET Webフォーム、ASP.NET MVC、Javaのサーバーの顔、Strutsの、PHPのフレームワークやルビーなどのサーバサイドWebプレゼンテーション層のフレームワークを使用しての疲れています。私はそれらのすべてにさよならを言って、私はAngularjsと活字体に挨拶しました。私のプレゼンテーション層は、ブラウザ上で実行されます。私は、それがPHPやASP.NETを実行しているWindows IISによって提供されている場合は問題ではない、またはそれは、Linux上で実行されているApacheウェブサーバーによって提供されている場合。私はどこでも働く一つだけのフレームワークを学ぶ必要があります。

ちょうど私の2セントます。

私にとって、JSF の最大の欠点は、プログラムで (動的に) 生成されたページのサポートが不十分であることです。
Java コードから動的にページを構築する (ページコンポーネントモデルを作成する) 場合。たとえば、WYSIWYG Web ページコンストラクターで作業している場合です。この使用例に関する適切なドキュメントは一般に入手可能ではありません。実験しなければならない点がたくさんあり、開発は静かに遅れています。多くのことは期待どおりに機能しません。しかし、一般的には、何らかの方法でハッキングする可能性があります。
幸いなことに、それは JSF の哲学やアーキテクチャに問題はないということです。(私の知る限りでは)十分に詳しく説明されていません。

JSF 2 はコンポーネント開発を容易にする複合コンポーネントを導入しましたが、動的 (プログラムによる) 構築のサポートは非常に貧弱です。動的なコンポジットコンポーネント構築の静かで複雑でほとんど文書化されていないプロセスを克服すると、いくつかのコンポジットコンポーネントをもう少し深くネストすると、いくつかの例外がスローされて動作を停止することがわかります。

しかし、JSF コミュニティはこの欠点を認識しているようです。これら 2 つのバグからわかるように、彼らはこれに取り組んでいます。
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

仕様に関して言えば、少なくとも JSF 2.2 では状況は改善されるはずです。

過去数か月にわたる Primefaces/JSF の経験について次のようにコメントしています。

「市販の」コンポーネントを使用できるのであれば、それほどひどいことではないと思います。
ただし、外に出るとすぐにうまくプレイできなくなり、カスタム UI が必要になります。- たとえば、プロジェクトには Twitter のブートストラップを使用する必要がありました。(Primefaces ブートストラップではありません)。
- これで、ページは次のように動作します。
  - ページが読み込まれます。
  - ユーザーは、Ajax 機能を備えた Primefaces と対話します。
  - Bootstrap の JavaScript バインディングが壊れる
  - 追加の JavaScript を実行してすべてを再バインドします

JavaScript の記述を避けるという JSF の約束は、Primefaces を使用しない場合よりも多くの JavaScript を記述することになりました。そして、その JavaScript は Primefaces が壊れているものを修正することになります。

再び「既製」のものを使用しない限り、それは時間の浪費です。Selenium を使用する必要がある場合も非常に醜い (Primefaces)。すべてを実行することは可能ですが、繰り返しになりますが、時間は限られています。

UX/デザインチームと協力していて、UI を迅速に繰り返す必要がある場合は、これを絶対に避けてください。jquery を学習したり、直接 HTML を書いたりするか、react/angular を検討することで時間を節約できます。

JSF には多くの利点がありますが、欠点についての質問なので、それについていくつかの点を追加させてください。

時間枠内で Web プロジェクトを実装する実際のシナリオでは、次の要素に注意する必要があります。

チームには、各シナリオに適した最良のコントロールを提案できる十分な上級メンバーがいますか？
最初の学習曲線に対応できる帯域幅はありますか?
JSF をレビューできる十分な専門知識がチーム内にありますか?
開発者が作ったものですか？

質問に対する答えが「いいえ」の場合、コードベースが保守不能になる可能性があります。

JSF一つだけ欠点があります。「JSF」の開発を開始する前に、あなたは明らかにWeb開発、コアJavaおよびフロントエンドアーキテクチャを理解する必要があります。

この頃は「新しい」JavaScriptフレームワークは、単に「JSF」コンポーネントベースのモデルをコピー/ペーストしてみてください。

は等スプリングMVC、自動改札、タペストリー、などのすべての「主流」の枠組みの中で、その複合部品を使用したJava EEのJSFは、最も精巧なプレゼンテーション層及び提供コンポーネント指向の技術です。これはHybridJavaによって提供されるソリューションに比べビット面倒で不完全です。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow