Flex/AIR開発でデザイナとの
協業を楽にする「yui」


特集:デザイナとプログラマを“結”ぶオープンソース(前編)

クラスメソッド株式会社
渡邊 佳一
2008/10/1


■ yuiの処理サイクル

 yuiを利用したアプリケーションの処理サイクルは以下のようになります。

  1. ViewまたはViewに配置されたコンポーネントがイベントを送出する
  2. Actionに記述されたイベントハンドラが処理される
  3. Actionのイベントハンドラ内で、LogicまたはHelperに処理を委譲する
  4. Logicは必要であれば、Serviceを利用して外部サービス呼び出しを行う
  5. HelperはViewに対する変更や更新を行う

 後から少しずつ、このレイヤオブジェクトがどのように役割を果たしていくのかについて説明していくので、ここではこのようになっているということだけ理解してもらえればいいと思います。

■ yuiは7つのライブラリに分かれる

 Alpha版のyuiを利用するために必要なライブラリはyui-framework1つだけでした。Betaでは、機能単位で7つのライブラリに分割しています。図2をご覧ください。

図2 akabanaのSVNリポジトリ
図2 akabanaのSVNリポジトリ

表1 yuiの7つのライブラリ
ライブラリ名 要約 依存するライブラリ
mx-wrappers mxのパッケージに依存しないようにするためのライブラリ なし
yui-core リフレクションAPIを含むライブラリ mx-wrappers
yui-framework yuiのメイン機能を提供するライブラリ mx-wrappers
yui-core
yui-logging
yui-service
yui-frameworks yuiのすべてのライブラリを統合するSWCファイルを作成するプロジェクト すべて
yui-logging ロギングAPIを含むライブラリ なし
yui-service S2Flex2用のRPC APIを含むライブラリ mx-wrappers
yui-core
yui-ds BlazeDS用のRPC APIを含むライブラリ mx-wrappers
yui-core
yui-logging
yui-service
※ yui-frameworksはライブラリプロジェクトではなく、各種フレームワークを統合させたSWCファイルをビルドするためのプロジェクトとなる

 このように、ライブラリを分割することで、機能を独立化し、単体または組み合わせでそれぞれ使えるようにしています。ライブラリは分割されましたが、Flex開発でyuiを使うということであれば、yui-frameworks(yui-frameworks.swc)を参照することで使用できます。

コラム 「yuiを理解するのに必要な3つの設計思想、CoC・DI・POJOとは?」

yuiの概要を知るうえで、3つの設計思想がありますので、それぞれ解説します。
  • 【1】 CoC(Convention over Configuration)

    少し前までのWebアプリケーションのフレームワークの特徴は、設定ファイルによって各レイヤの役割、依存関係を解決するものでした。開発者はその設定が正しいものか確認をする必要がありました。XMLで記述された設定ファイルはアプリケーションの規模が大きくなればなるほど膨大になり、管理の面から考えても面倒なものでした。

    それを解決する手段として生まれたのが、この「CoC」です。CoCはRailsで支持を受けた革新的な哲学で、「規約は設定に勝る」というものです。Railsを使う開発者は規約を守るだけで済むようになり、フレームワーク側で自動的に適切な設定をしてくれます。こうすることで、記述を減らし、規約に従わなければ動作しない状況を作り出すことができ、コードの平準化が可能になります。

  • 【2】DI(Dependency Injection)

    「DI」は、直訳すると「依存性の注入」となります。ここでいう「依存性」とは、プログラムにおける「オブジェクトがほかのオブジェクトを利用するコード」を指します。DIはその依存性を実行時に注入するため、このような名前になっています。

    DIはJava開発を変える設計思想といわれており、SpringやSeasar2などのJavaフレームワークですでに採用されています。このDIを利用することによって、オブジェクトがほかのオブジェクトへ依存することを軽減し、独立性を高めます。独立性を高めることで変更に強いシステムを作成可能となります。

  • 【3】POJO(Plain Old Java Object)

    「POJO」とは、「フレームワークなど、特定の仕組みに依存しないJavaオブジェクト」のことです。

    逆に特定の仕組みに依存するJavaオブジェクトとは、例えばサーブレット/JSPプログラミングを行う場合、必ずHttpServletクラスを継承するといった制約があります。つまり、オブジェクトが特定の仕組みに依存しないということは、「オブジェクトとして独立性がある」といい換えられます。そして、POJOはオブジェクトが特定の仕組みに依存していないので、単体テストを行ううえで大きく役に立つのです。
yuiはこの3つの設計思想に基づいて作成されています。yuiを利用して作成したアプリケーションは以下の特徴があり、シンプルで、拡張性、保守性の高いシステムを作成可能にしています。
  • CoCによって、設定ファイルを記述することなくオブジェクトをレイヤに分け役割を明確化している
  • DIによってそれぞれの関連を解決し、レイヤ間の依存性を最小にしている
  • 各レイヤオブジェクトは、POJOのようなシンプルでテストしやすいオブジェクトとして機能している

分業を楽にするyuiの“5”大機能

 では、上記の設計思想がどのように利用され、生かされているのか。次にyuiの5大機能について説明します(下記リストはインデックスになっています)。

  1. 規約を定める「Naming Convention」
  2. イベントハンドラをViewに関連付ける「Auto Event Handler」
  3. 各レイヤのフィールドに対してDIを行う「Customizer」
  4. ログ管理/操作を行う「Logging API」
  5. RPC接続を可能にする「RPCコンポーネント」

■ 機能【その1】規約を定める「Naming Convention」

 「Naming Convention」はyuiにおける規約を定める機能を指します。CoCの設計思想に従い、この規約を守ることで設定ファイルなしで、各レイヤオブジェクトに対して役割を与え、関連性を解決します。

図3 パッケージ構成例
図3 パッケージ構成例

 yuiのNaming Conventionはクラス名と、パッケージに制約を持たせています。そのためパッケージ構成が一貫し、見た目に分かりやすくなります。図3にパッケージの定義例を示します。「datavisualization」という1機能に対して、「action」「helper」「logic」「view」という4つのパッケージが存在し、その下に各レイヤオブジェクトが存在している点に注目してください。

 正しく構成された各レイヤオブジェクトは、機能としての区切りであるパッケージを2つ上に、1つ上に各レイヤオブジェクトのパッケージを持ちます。図3に示した例のようにクラスまたはオブジェクトを配置、作成すると、Naming Conventionの機能によって、それぞれにレイヤオブジェクトとしての役割を持たせます。

 具体的には、表2のような命名規則に従いパッケージとその中にクラスを作成することでそれぞれのオブジェクトに役割を与えます。

表2 Naming Conventionの命名規則
命名規則 ファイルタイプ 役割 担当
view
xxxView
.mxml MXMLコントロールの配置など、画面レイアウトの定義(UI) デザイナ
helper
xxxHelper
.as
(ActionScriptクラス)
Viewに表示するデータの適用やViewの振る舞いに対する処理を行う デザイナ
プログラマ
action
xxxAction
.as
(ActionScriptクラス)
Viewが送出するイベントに対応したイベントハンドラを定義する プログラマ
logic
xxxLogic
.as
(ActionScriptクラス)
外部インターフェイス呼び出しやデータの処理などビジネスロジックを行う プログラマ
※ 1機能の役割が小さい場合、Actionの中にLogicの役割を持たせてViewとHelperとActionの3つで構成することもできる
※ そのほか、「xxxService」といったRPCを行い、外部インターフェイスを定義するレイヤオブジェクトもあるが、S2Flex2を使用する場合に
は別途クラスとして定義する必要はない

 Naming Conventionによって役割を与えられると、各レイヤオブジェクトはそれぞれの役割を最大限に発揮するために拡張されます。次に、その各レイヤオブジェクトを拡張する機能について解説します。

■ 機能【その2】イベントハンドラをViewに関連付ける「Auto Event Handler」

 Auto Event Handlerは、Actionクラスに定義されたイベントハンドラをView、またはViewに配置されたコンポーネントから送出されるイベントに対する処理として関連付けを行う機能です。

 具体的に、Auto Event Handlerで自動的に関連付けを行うためには、次のようにする必要があります。

  • View内に配置したコンポーネントにidまたはnameを付けること
  • Actionクラスに以下のシグネチャで関数を定義すること
public function function_name( event:XxxEvent ):void { }

 「function_name」は、【Viewのidまたはname】+【イベント名】+「Handler」となります。例えば、Viewに配置したButtonコンポーネントに対して、Clickイベントに対応するイベントハンドラをActionクラスに定義する場合、以下のように記述します。

xxxView.mxml
<?xml version="1.0" encoding="utf-8"?>
<mx:Panel xmlns:mx="http://www.adobe.com/2006/mxml">
  <mx:Button id="button" />
</mx:Panel>

xxxAction.as
public function buttonClickHandler( event:MouseEvent ):void{
    //イベント処理
}

 さて、ここで質問です。Viewに配置したコンポーネントにIDが必要だとすると、上記のxxxView.mxml内で定義されたPanel、つまりView自体に対してイベントハンドラをひも付ける場合はどうしたらいいでしょうか?

 実はfunction_nameの付け方には2通りあります。View内にコンポーネントとして定義された場合と、Viewのドキュメントルートとして定義されたコンポーネントの場合です。ドキュメントルートとは、View(MXML)に定義されたルートのコンポーネントのことを指します

  1. Viewの子供以下として定義されたコンポーネントのfunction_nameの定義は、【対象のコンポーネントのidまたはname】+【Event名(1文字目は大文字)】+「Handler」となる

    xxxAction.as(「comboBox」というidが付いたコンポーネントにchangeイベントをハンドリングさせる場合の定義方法)
    public function comboBoxChangeHandler( event:Event ):void {
        //イベント処理
    }

  2. Viewのドキュメントルートとして配置されたコンポーネントのfunction_nameの定義は、「on」+【Event名(1文字目は大文字)】+「Handler」となる

    xxxAction.as(xxxViewのドキュメントルートのコンポーネントにinitializedイベントをハンドリングさせる場合の定義方法)
    public function onInitilizedHandler( event:FlexEvent ):void {
        //イベント処理
    }

 Flex/AIR開発では、このように「コンポーネント」と呼ばれる表示オブジェクトに対して、ロジックを追加してアプリケーションを構築していきます。そのため、通常はViewとロジックが密に結合してしまいます。しかしyuiを利用すると、Viewまたは、そのコンポーネントにAuto Event Handlerによってロジックが自動的に関連付けられるため、ソース上はActionとViewの関連がまったくありません。

 こうすることで、デザイナはViewの作成に専念でき、プログラマはViewが発生するイベントを意識するだけでいいのです。

 また、この機能はコード量を減らすことにも一役買っています。フレームワーク側で解決してくれる問題であれば、検証の手間を省くこともできます。後ほど説明しますが、正しくイベントハンドラがコンポーネントに登録されたかどうかはログで確認できます。

 引き続き次ページでは、yuiの“5”大機能について解説しします。

1-2-3

 INDEX
特集:デザイナとプログラマを“結”ぶオープンソース(前編) 
Flex/AIR開発でデザイナとの協業を楽にする「yui」
  Page1
RIA開発におけるデザイナとプログラマの協業問題
コラム 「Flexのフレームワークといえば“Cairngorm”ってなかったっけ?」
「yui-frameworks」って、どんなもの?
コラム 「Flexであまり考慮されない“テストのしやすさ”」
Page2
コラム 「yuiを理解するのに必要な3つの設計思想、CoC・DI・POJOとは?」
分業を楽にするyuiの“5”大機能
  Page3
yui(結)でデザイナとプログラマを“結”び付けよう




HTML5 + UX フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

HTML5+UX 記事ランキング

本日 月間