JSFでjsfc属性を使ったデザイナとの協業をすべきか。
デザイナがHTMLでwebデザインを行い、SEがJSPに変換する。仕様変更が起きれば再度HTMLを直し、再変換。テストもやり直し。
デザイナとの協業は過去様々な検討が行われてきたが永遠のテーマであり銀の弾丸はない世界に見える。変換ツールが出たり、影響範囲を見きってテスト範囲を極小化したり。
ポイントはデザイナ用のHTMLとJSPの二重管理という構造にあるように思う。だったら一元化すればいいじゃないか。というコンセプトがJSFのjsfcだ。
昨今ajaxやらHTMLやら、果てにはクライアントMVCなんていう単語も出てきて、クライアント重視にシフトしていっている流れ。
その流れを受けたものかはわからないが、f:ajaxタグで一部JavaScriptを意識しない開発を実現したり、UIコポーネントツリーでクライアント側のDOM構造を表現したりと、JSFはクライアントにあった技術をサーバサイドに寄せて実現する動きをしている。
では、jsfcは？というと、サーバサイドで解釈できる動的ページでありながら、ブラウザ単体でも表示でき、デザイナによる確認を可能にすることを目指している。
気になるのは、そんな銀の弾丸なんてあるのか？ということ。賛否わかれているが、以下ではテーブルの構築部分のように、一見実現できなさそうな部分も違う形で実装でき、有益なものとして紹介されている。
*1
デザイナ側から見ると多少不十分で、開発側から見ると多少作りづらい面がでてくることは否めない。ただ、どんどんデザインをスピーディーに変えていくような局面においては、力を発揮する。アジャイルと呼ばれる開発スタイルではマッチする。
