Java/JavaServer Faces(JSF)/調査メモ1

• [ Prev ]
• [ Next ]
• [ Java ]

JSFとはどんなものか、いくつかググってみた参考URLメモ。

• JavaServer Faces - Wikipedia, the free encyclopedia
  • http://en.wikipedia.org/wiki/JavaServer_Faces

JavaEEに含まれるHTMLなどの画面系の仕様であり、JSRで調整されている。
また数年ごとにバージョンアップされており、開発のしやすさや機能性は向上している。
JSF 1.x系の時の評判は、一旦忘れて、素直にJSF 2.x系の最新版を調べたほうが良さそう。

JSPとは別物と考え、特にJSF 2.2で入ってきたらしいFaces Flowについては画面遷移の制御で、むしろSpring WebFlowやASP.NETアプリに近いアーキテクチャになってる・・・ような、印象を受けた。

• Java EE vs JSP vs JSF - Stack Overflow
  • http://stackoverflow.com/questions/23707036/java-ee-vs-jsp-vs-jsf
• Difference Between JSF and JSP | Difference Between | JSF vs JSP
  • http://www.differencebetween.net/technology/difference-between-jsf-and-jsp/
• JSF Versus JSP, Which One Fits Your CRUD Application Needs? (Part 1) | Javalobby
  • http://java.dzone.com/articles/code-less-do-more-jsf-versus

JSF 2.xや2.2系列について、HTML5との親和性が向上した云々：

• JSF 2.2 and HTML5
  • http://www.infoq.com/jp/news/2013/07/jsf22-html5
• JSF 2.xについてEd Burns氏が語る
  • http://www.infoq.com/jp/news/2012/02/jsf-update-2.x
• JSF2.2でHTML5のタグを少し試してみる その1 - Challenge Java EE !
  • http://kikutaro777.hatenablog.com/entry/2013/07/27/154950
• HTML5 and JSF
  • http://www.oracle.com/technetwork/articles/java/enterprise-html5-2227136.html
• JSF 2.2: HTML 5 Support | Javalobby
  • http://java.dzone.com/articles/jsf-22-html-5-support

JSFでのリッチなUIライブラリとして、PrimeFacesというのがある。HTML5にも対応しているらしい。

• PrimeFaces 5 リリース - モバイルサポート刷新，プッシュサポートを大幅に改善
  • http://www.infoq.com/jp/news/2014/06/primefaces5
• PrimeFaces
  • http://www.primefaces.org/primeui/demo.html
• Getting Started With PrimeUI – HTML5 With Style | Beyond Java
  • http://www.beyondjava.net/blog/started-prime-ui-html5-style/

他にもJBossのRichFacesがあった。

• RichFaces - JBoss Community
  • http://richfaces.jboss.org/

ただ、フロント開発がJavaScriptともに大きく揺れ動いている昨今、HTML5との兼ね合いや、訴求対象の開発者のカテゴリなどで、色々将来どうなの？的な話も見つかる。
例えば以下の記事は、JSFで実際に開発してみて、もう沢山だ！となった人が色々と愚痴をまとめてる。コメント欄も炎上してて、JavaEEのMVC仕様策定者もコメントしてたりで、大変面白いことになってる。

• Why You Should Avoid JSF | Javalobby
  • http://java.dzone.com/articles/why-you-should-avoid-jsf

実際にJSFの内部のライフサイクルや、どうデバッグするかの解説記事。これを見るとASP.NETと似通った部分があり、サーバサイドとフロントのJavaScriptサイドの両方の知識が要求されることが分かる。

• How JSF Works and how to Debug it - is Polyglot an Alternative? | Javalobby
  • http://java.dzone.com/articles/how-jsf-works-and-how-debug-it

余談だが、JAX-RSやSpring MVCのちゃんぽん的に、JavaEEでMVC（つまりURLマッピングに基づくアクションコントローラ形式）のフレームワークの仕様化が始まっている。

• Java EEのためのMVC 1.0JSR
  • http://www.infoq.com/jp/news/2014/09/mvc-1.0-jsr

個人的には、JSFにせよMVCにせよ、どんどん複雑・多様化していくWebフロントエンド技術で、どうしても発生する「複雑さ」をどこに持っていくかの問題になってきてる気がする。
AngularJSなどの最近のWebフロント技術は、基本的にブラウザ側のHTML+JSで複雑さに対応し、サーバサイドはAPIだけに絞る方向に見える。
一方でJSFやASP.NETの世界は、複雑さをサーバサイドの状態管理で対応しようとしていて、そのため、サーバサイドのライフサイクルとフロントエンド側のJSの両方に、微妙に複雑さがまたがってしまってる感じを受ける。
また業務アプリとそれ以外でも断絶はある。消費者向けのコンテンツサイトにおいて、業務アプリのような複雑なUIや画面遷移は必要ない。むしろREST的な世界観を求められるため、状態に紐付いたURLは敬遠される。一方で業務アプリはURLのREST性は不要なので、サーバサイドで状態管理された、非RESTなURLや画面遷移は許容される。また大規模開発をサポートするために、コンポーネント指向の仕様やフレームワークになっていく。

個人的には、もはやWebフロントの複雑性はサーバサイドで状態管理できる範囲を超えていて、JSFや.NET系のサーバサイド＋フロントJSで状態管理を連携させるアーキテクチャは、開発者の負担が上がっているのではないかと思う。
むしろサーバサイドはAPIと初期HTMLページを表示するだけのものと割り切り、JS側でDOM構造の状態管理を行う方が、境界が明確で分かりやすい。（学習曲線はこの際無視する）
その上で、消費者向けのコンテンツサイトなどと、業務アプリでの複雑なUIコンポーネント制御とで、使用されるJSライブラリは異なってくるだろう。

・・・とはいっても、JSFはコンポーネント指向＋画面フローの制御という点に旨味があるのは確かなで、一緒についてくる「苦味」とどこまで・どの位付き合っていけるかはもう少し勉強してみないと分からなそうであります。

• [ Prev ]
• [ Next ]
• [ Java ]