JSFを使用しない理由[非公開]

64

StackExchangeは初めてですが、あなたが私を助けることができると思いました。

レガシーJSPソリューションを置き換える新しいJava Enterpriseアプリケーションを作成しています。多くの変更により、UIとビジネスロジックの一部は完全に再考され、再実装されます。

Java EEの標準であるJSFが最初に考えられました。最初は良い印象がありました。しかし今、私は機能的なプロトタイプを実装しようとしていますが、それを使用することに関して本当に深刻な懸念があります。

まず第一に、それは私が今まで見た中で最悪で最も雑然とした無効な擬似HTML / CSS / JSミックスを作成します。ウェブ開発で学んだすべてのルールに違反しています。さらに、レイアウト、デザイン、ロジック、サーバーとの通信など、決して緊密に結合されるべきではないものが一緒に投げられます。CSSでスタイリングしたり、UIキャンディー（構成可能なホットキー、ドラッグアンドドロップウィジェットなど）を追加したりなど、この出力を快適に拡張する方法がわかりません。

第二に、それはあまりにも複雑です。その複雑さは際立っています。あなたが私に尋ねると、それは基本的なウェブ技術の貧弱な抽象化であり、最終的には不自由で役に立たない。私にはどんな利点がありますか？考えてみれば、なし。何百ものコンポーネント？さらに、数万のHTML / CSSスニペット、数万のJavaScriptスニペット、および数千のjQueryプラグインが表示されます。これは本当に多くの問題を解決します-JSFを使用しない場合はありません。または、フロントコントローラーパターン。

そして最後に、2年後にはやり直さなければならないと思います。最初のGUIモックアップをすべて実装する方法がわかりません（さらに、チームにはJSFエキスパートがいません）。どういうわけか一緒にハッキングできたかもしれません。そして、さらにあります。ハックをハッキングできると確信しています。しかし、いつかは行き詰まってしまいます。サービス層より上のすべてのものがJSFを制御しています。そして、最初からやり直す必要があります。

私の提案は、JAX-RSを使用してREST APIを実装することです。次に、クライアント側のMVCでHTML5 / Javascriptクライアントを作成します。（またはMVCのフレーバー..）ところで。部分的なAndroidフロントエンドも開発しているため、とにかくREST APIが必要になります。

私は、JSFが今日の最良のソリューションであることを疑っています。インターネットが進化しているので、なぜこの「レーキ」を使用する必要があるのかわかりません。

さて、賛否両論とは何ですか？JSFを使用しないという点を強調するにはどうすればよいですか？私の提案よりもJSFを使用する長所は何ですか？

— ブルーノ・シャッパー
ソース

24

これは、新しいユーザーからのよく書かれた質問です。投票の際にコメントを残すことを検討してください。

— シーフマスター

2

すべてを書き直しているので、JSFを使用しないことを検討するだけでなく、Javaをまったく使用しないことも検討します。最新のスクリプト言語（つまり、 PHPやPerlではない）は、非常に優れており、開発者にとって使いやすいです。

— シーフマスター

11

私は下票しませんでしたが、これは質問ではなく、暴言です。VainはJSFが嫌いだと決心しましたが、今ではJSFを使用しないより多くの理由を求めていますか？

— マイケルボルグワード

4

多くのサービスを使用して、アプリケーションが大規模（複雑および/またはスケーラブル）および/または分散される場合、Javaが最良の選択です。アプリケーションがこのカテゴリに収まらない場合（それほど複雑ではなく、スケーラブルである必要もありません）、Python（Django）またはRuby（Rails）の方が適しています。JSFの複雑さには、JSFのパワーという利点があります。それに代わるものとして、Javaが必須の場合は、Spring MVCやStruts 2などの他のWebフレームワークをご覧ください。

— m3th0dman

14

これはバックアップを探している暴言であり、質問そのものではありません。

26

JSFを検討する理由は少なくとも1つあります。

これは、Java EEスタックの標準的な部分であるため、利用できるようになります-と作業は非常に、非常に長い時間のために、すべてのJava EEコンテナに- 。また、Java EE仕様に厳密に準拠している場合は、そうする必要なしに維持します。

これがあなたにとって関心事であるなら、あなたはそれを考慮すべきです。ほとんどのソフトウェアは、設計者が考えるよりも長生きします。特に、作成する際に考慮する場合はそうです。

4

そのことはよくわからない。J2EEの場合、使用されるj2eeのバージョンへの変更を含む、長年サポートされる予定のシステムを話す場合は特に、「標準」および「作業」という言葉は明確に書かれていません。

— マガラン

7

私の（限られた）JSFの経験では、この議論は実際には成り立ちません。アプリケーションがJSFの1つのバージョンに固執し、新しいバージョンへの適切な移行パスがないことがわかりました。確かにアプリサーバーはそれを実行しましたが、それはあなたが高額のサポート契約で燃やすために多額のお金を持たない場合に得られるすべてのサポートについてでした。

— イェンスシャウダー14

@JensSchauder私の経験では、移植可能なアプリケーションを作成し、そのバージョンのjsfを移行およびアップグレードできます。これには、仕様を把握し、実装ではなく仕様をコーディングする必要があります。Hibernateの代わりにJPAのコーディングが機能するため、機能します。何年もそれをやっています。

— イマジョロス

14

さて、賛否両論とは何ですか？JSFを使用しないという点を強調するにはどうすればよいですか？私の提案よりもJSFを使用する長所は何ですか？

あなたはすでに短所について気にかけていたようです、そして私はそれらのいくつかに同意する必要があります（レイアウトとロジックを十分に分離せず、結果のHTMLはしばしば凶悪です） Facelets（これは非常にお勧めしますが、出力は間違いなく有効です）。

だからここにいくつかの長所があります：

PrimceFacesやRichFacesのような非常に強力なコンポーネントライブラリには、すぐに使用できる多くの機能があります。これらはあなたの要件をカバーしていれば、多くの作業を節約できます（もしあなたが彼らによってカバーされていない交渉不可能な要件を持っているならそれほど多くはありません）。
複合コンポーネントは、ページをモジュール化する非常にクリーンな方法を提供します
JSFは残りのJava EEと非常によく統合されます
コンポーネントの再レンダリングによるAJAXは本当に簡単で便利です

しかし、これらの利点はどれもそれほど大きくないので、チームがすでに経験している他のフレームワークよりもJSFを使用する必要があります。

— マイケル・ボルグワード
ソース

1

それはIDではなく、無効な属性です。タブビューの「ロール」や「aria-expanded」など。これを修正する方法を知っていますか？

— ブルーノシェーパー

1

@Vain：いいえ、別の問題のようです。おそらく、私が使用しなかったコンポーネントや新しいコンポーネントの問題です。代替レンダラー（理想的にはデフォルトのレンダラーの1つまたは2つのメソッドを単にオーバーライドする）を指定することにより、JSFコンポーネントのHTML出力を変更することは可能ですが、もちろんこれは有効なマークアップを取得するためだけに行う必要のあるものではありません。

— マイケルボルグワード

1

凶悪なHTMLは、使用されている実装によるものです。参照JSF実装のデバッグモードは、これが特に悪いことは私の理解です。より良いHTMLを生成するためのより良い設定を知っていますか？

1

@ThorbjørnRavn Andersenはい、無効なHTMLの問題は実際にはPrimeFacesの問題です。jQuery-UI上に構築されているため、これを使用します。あなたのアドバイスは何ですか。他のライブラリを使用する必要がありますか？有効なHTMLが本当に好きです。私にとって、それは単に必須です。

— ブルーノシェーパー

1

ここで私の最初の質問を再訪して、あなたのプロについてのいくつかの経験を共有したいと思います。私たちはJSFと協力しており、その経験では再びそれを選択しません。ほとんど何も期待どおりに動作し、すぐに使用できます。はい、強力なライブラリがあります。しかし、私たちはすべてのコンポーネントを自分たちでやったのです。なぜなら、それらは私たちが必要とするほどうまく機能しないからです。スクロール中に遅延読み込みを行う独自の「DataTable」がどれだけ高速に作成されたかは驚くべきことです。複合コンポーネントは機能しませんでした。理由を説明することはできませんが、バグがあると思います。AJAXの再レンダリングは、実際にはクライアント側のJSにとって苦痛です。

— ブルーノシェーパー

9

JSFは、多くの主要ベンダー（FOSSベンダーを含む）によってすぐにサポートされることを意味する標準である、Java用の適切なステートフルWebフレームワークです。強力なサードパーティライブラリサポート（PrimeFaces、IceFacesなど）があります。ただし、そのステートフルな性質（および他の多くのこと）のために、基本的に「Webを中断します」。Matt RaibleによるJVMベースのWebフレームワークの比較を参照してください。通常、JSFは最後に近づいています。

編集-JSF 2.2を使用すると、以前のようにWebを破壊しないと主張し始めることができます。実際、HTML5との統合がすべてひどいわけではありません:-)。

— マルティン・ベルブルク
ソース

1

それは確かに「ウェブを壊します」。そして、マット・レイブルの比較のおかげで、それを知りませんでした。

— ブルーノシェーパー

3

JSFは必ずしもステートフルではないことに注意してください。私はそれが頻繁にそうであることに同意しますが、ステートレスGETベースのリクエストにはかなり良いサポートがあり、フォームを使用しない場合はまったくステートがありません。

— アルジャンTijms

フェアポイントアルジャン、私は多くのステートフルな使用を見てきました。

— マーティンバーバーグ

Raibleのプレゼンテーションへのリンク：slideshare.net/mraible/...

— zaidaus

6

従来のJSP / Struts 1.0アプリケーションがありました。Struts 2、JSF、およびStruts 1以降に発生した他のすべてをスキップし、Spring 3.0にジャンプしました。私たちのウィッシュリスト（Eclipse IDE、MVC、REST）のサポート（およびアクティブなコミュニティ）があります。さらに、jqueryのためにヴィンテージの自家製Javascript / ajaxを捨てました。

YMMVですが、Springはスムーズな移行でした。

— jqa
ソース