新着情報

プレゼンテーション技術

Webアプリケーション開発におけるプレゼンテーション技術は、現在２つの大きな流れの中で解を模索中の状態です。 １つはHTMLをベースとした流れ、そしてもう一つはリッチクライアントと呼ばれるクライアントで動作するプログラムにて表現する流れに分けられます。 どちらにも特徴があり、これからもビジネスシーンによって使い分け、共存していくと予想されます。
プレゼンテーション技術

HTMLクライアント

様々な技術が跳梁跋扈している状態ですが、ソースのスッキリ感を求める流れと、HTMLとして表示できる事を求める流れが あるようです。

JSP2.0

これまでのJSP1.2ではユーザが定義したタグに機能を持たせることができる「カスタムタグ」が使用されました。 しかし、制御分がタグに置き換わることによりJSPをHTMLエディタで開くとプレビューできないなどの問題が あり、このような問題を払拭するべく、JSP2.0は以下のような新機能が取り込まれました。
※詳細な説明はこちら「JSP2.0」参照

  • 1) EL(Expression Language)　（式言語と呼ばれることもあり）★1
  • 2) タグファイル
  • 3) JSPフラグメント
  • 4) SimpleTag

JSTL（JSP Standard Tag Library）

JSPのカスタムタグのJava標準ライブラリ。JSPによる開発の短所をそのまま受け継いでいます。 JSTLのタグは次の4つに分類されています。これらのタグに対して、属性値としてELを使用(★1)することができます。

1) コア
単純な値の出力やif、forEachなどの制御分を含んでいる基本的な機能を提供します。
2) 国際化/書式
国際化のタグはメッセージリソースの出力やタイムゾーン、文字コードの制御などができます。 書式は日付や数値のフォーマットを行います。
3) SQL
SQLによるDBの操作ができます。
4) XML
XMLに対する様々な操作をおこなうことができます。XSLTを使用した変換処理も可能となります。

Taglibs

Jakartaプロジェクトで開発されている便利なカスタムタグのライブラリでJSTLのリファレンス実装も持っています。 JSPによる開発の短所をそのまま受け継いでいる。 JSPからのApache Log4j によるログ出力できる機能、JNDI操作、JSPからメール送信など様々な機能があります。

Velocity

Jakartaプロジェクトで開発されているJavaベースの汎用テンプレートエンジンです。 HTMLの生成だけでなく、広くテンプレートの穴埋めに使用するエンジンとして開発されています。 あらかじめ作成しておいたテンプレート（HTML、XML、テキストなど）のフィールドに対して、実行時にパラメータを 割り当てて、レイアウトやデータを生成します。 VTL（Velocity Template Language）と呼ばれるELと同様の”$”で始まる変数の部分をコレクション内の値に 置き換えてくれます。その他、ifなどの制御文も用意されています。

Javaで開発されていることから、Javaから使用することが前提になっています。また、VelocityはWeb開発用のフレームワークと併用することが可能な為、組み合わせて利用することが一般的です。

JavaのWebアプリケーション開発環境への設定方法
1) velocity-tools-*.jar、velocity-dep-*.jar をクラスパスへ追加する。　*：はバージョンナンバー
2) 設定ファイル（velocity.properties）をWEB-INF以下の任意のディレクトリに配備。
3) toolbox設定ファイル（velocity-toolbox.xml）をWEB-INF以下の任意のディレクトリに配備。
4) web.xmlにVelocityViewServletのサーブレット配備、パラメータ設定、マッピングを追加する。

Tepestry

Jakartaプロジェクトで開発されているプレゼンテーション部分に特徴のあるフレームワークです。 JSPを使用せず、HTMLに近い独自の文法でビューを記述します。
拡張子も.htmlでよいので、HTMLエディタやブラウザでプレビューすることができます。
Tepestryの最大の特徴はWebコンポーネントを中心とした開発で、jwcidという属性タグがページ使用のWebコンポーネント にリンクすることによって、ロジック部分をHTMLの外に追い出しています。 これによってHTMLがほぼ原形を留めているのでデザイナとの分業を究極に求めた構造だと言えます。

Turbine

Jakartaプロジェクトで開発されているフレームワークでプレゼンテーション部分に多くの機能を保有していますが、開発手法が束縛される、開発が複雑になるなどの問題があります。
ビュー部分はVTLやJSP（注：設定変更要）を使用することができます。
Turbineのフレームワークには「Page」、「Action」、「Layout」、「Screen」、「Navigation」の5つのモジュールがあります。

1) Page
ページ生成を行う際に最初に実行されるモジュール。
リクエストの中にActionが定義されている場合、Actionモジュールを実行します。
Actionモジュールを実行後、Layoutモジュールを実行します。
2) Action
Pageモジュールにより実行されます。
HTMLフォームのsubmit時にフォーム情報を処理する為にActionモジュールが実行されます。
入力チェック処理からDB格納までの処理を行います。
3) Layout
Pageモジュールにより実行されます。
Webページの物理的なレイアウトについて定義します。
Screenモジュールを実行して、Navigationモジュールを実行します。
4) Screen
Layoutモジュールによって実行されます。
HTMLのbody本体にあたるものです。
HTMLを生成する際にはテンプレートエンジンを使用します。
5) Navigation
Layoutモジュールによって実行されます。
ページの上下部やサイドによくあるWebサイトをナビゲーションする為のHTMLを生成します。
HTMLを生成する際にはテンプレートエンジンを使用します。

現在はTurbineからTorque ( O/Rマッピング ) と Fulcrum ( サービスフレームワーク )に独立して、それぞれが各レイヤーで注目されています。
Turbineまだまだ注目されていない為、情報も国内では少ないです。

Cocoon

XMLファイルをXSLやXSLTによってHTMLやPDF、テキストなどに変換する技術です。 XMLに対してロジックまたはカスタムタグを追加する開発方法で、HTMLへの変換は複数の変換規則を施しており、パイプラインというフロー定義によって制御します。 XMLからビューを生成するという特徴がありますが、このような技術を開発に使用することは開発者も選択しづらいものがあり、普及するとは言い切れない部分があります。 なお、使用できる言語は以下のとおりです。

・XSLT(XML Stylesheet Language Transformations)
XMLによって記述された文書を他のXML文書に変換するための簡易言語です。 XML文書の構造を別の形式に変形するための変換ルールを記述するもので、記述されたXSLT文書は「スタイルシート」と呼ばれます。 もともとはXSLの一部として変換処理を行なうために開発されていましたが、単独で使用することも可能です。 おもに、XML文書からHTML文書やテキスト文書への変換などに使用されます。
・XSP(eXtensible Server Pages)
感覚的にはXML文書の中にJavaのlogicを記述したものです。JSPと同様にリクエストに対してダイナミックなページ作成が出来ます。 JSPのXML版と言えばイメージできるかと思います。
・XSLFO(XML Stylesheet Language Transformations Formatting Object)
XML文書を直接PDFファイルに出力（レンダリング）する機能です。 もっと正確に言えば、XMLで記述されXML文書中のテキストを二次元にレイアウトするための言語ということです。
・SVG(Scalable Vector Graphics)
PDF文書の中にグラフィック出力のために使用する言語です。 参照：http://www.adobe.co.jp/svg/main.html
・WAP(Wireless Application Protocol)
cocoonではアクセスしてきたブラウザの種類を検出して異なるスタイルシートを適用してブラウザの種類に合致したHTML出力を行う事が出来ます。

JSF（Java Server Faces）

JCP（Java Community Process）で仕様が策定されており、今後Java標準という位置付けになると注目されています。 Webアプリケーションのフレームワークとして知られていますが、クライアント/サーバアプリケーション形態に使用できる 柔軟な構造を持つことが特徴です。 UIコンポーネントを画面（JSPなど）にデザインすることによって開発を行います。 コンポーネントに対して割り当てられるJavaクラスはStrutsではFormBeanやActionのようにフレームワークに依存した クラスを作成する必要がありましたが、JSFではPOJO（※1）で作成することができます。 JSFは特定のプレゼンテーション技術に依存しない構造を持っていますが、通常JSTLと併用して開発を行います。 JSFは処理の役割ごとに独立した構造を持ち、抽象的なインターフェースによって結合していることから、抽象的な インターフェースに従い別の実装に変更したり、新しい機能を追加することによって振る舞いをカスタマイズする ことができます。

※１：POJO（Plain Old Java Object）　⇒　純粋なJavaソースコードで記述されたJavaBeans。

１．現在の代表的なJSF実装

・MyFaces
オープンソース
・Refernce Implementation
無償（ソース公開）、改変や再配布は禁止の為、非オープンソース
・ECruiser
有償
・The Keel Meta-Framework
オープンソース


２．コントローラの動作「faces-config.xml」

コントローラであるFacesServletはJSF設定ファイルfaces-config.xmlで動作を定義します。


（１）画面遷移の定義

<from-view-id>　遷移元URL　</from-view-id>
<navigation-case>
  <from-outcome>　処理からのアクション名　</from-outcome>
  <to-view-id>　遷移先URL　</to-view-id>
</nabigation-case>

（２）Managed Bean（モデルクラス）の設定
1) バリュー・バインディング・・・UIコンポーネントに設定された値とBeanのプロパティを対応付ける。
2) コンポーネント・バインディング・・・UIコンポーネントそのものとBeanのプロパティを対応付ける。

※概要を図で説明します。


３．JSFのライフサイクル

1) ビューの復元（Restore View）
リクエスト元の画面に対応するUIコンポーネントツリーを復元します。
2) リクエスト値の適用（Apply Request Values）
リクエストに入力された値をUIコンポーネントツリーにUIコンポーネントに設定します。
3) 入力値の検証（Process Validation）
UIコンポーネントに入力された値の変換と検証を行います。
4) モデル値の更新（Update Model Values）
UIコンポーネントの値をManaged Beanのプロパティに反映します。
5) アプリケーションの起動（Invoke Application）
ボタンなどに対応付けられているManaged Beanのアクションメソッドを実行し、遷移先画面を決定します。
6) レスポンスのレンダリング（Render Response）
遷移先画面のUIコンポーネントツリーから、クライアントへ返すデータ（HTMLなど）に変換します。

リッチクライアント

Webブラウザベースのクライアントは、クランアント／サーバ型のクライアントと比較した場合、必ずしも利用者にとって使いやすいものではありませんでした。Web化が進む中、利用者の使い勝手の悪さは、無視できない問題として顕在化してきました。
これに対し、リッチクライアントはWebアプリケーションシステムであるにも関わらず、利用者の操作性／利便性を犠牲にしないクライアント（あるいは技術）です。
主な特徴として、「高い表現力」、「高い操作性」 、「ソフトウェア配布の容易さ」があげられます。


歴史から紐解き、様々な調査により、リッチクライアントを説明しているサイトをご紹介します。
⇒http://www.thinkit.co.jp/free/tech/5/1/1.html

プレゼンテーション技術徹底比較

ここまでプレゼンテーション技術のラインナップをご紹介しました。では実際のプロジェクトではどのような視点で、 どのような点を重視して採用可否を決定するのでしょうか。
ビジネスとしての視点を含め比較してみます。

⇒プレゼンテーション技術比較