これは RuntimeRevolution 1.1.1 のヘルプにある文書を邦訳したものです。この文書の文責はＵＤＩにあり、またＵＤＩはこの文書についての一切の債務を負いません。 間違いがありましたら eudio@chabashira.co.jp までお知らせ下さい。この文書は必要と思われる時に適宜アップデートされます。

Help -> Tutorials -> Independent Study


1. Before you start
始める前に

　このチュートリアルを始める前に、最初のチュートリアルである Getting Started で、Revolution でアプリケーションを作る方法を修得しておきなさい。各ツールの使い方、オブジェクトの作り方、そしてスクリプトの書き方は知っておく必要がある。

　また Revolution の基本を理解しているだけでなく、実際に自分のスタックを作った経験も必要である。これは中級向けのチュートリアルである。

　ティップス：　もし判らない単語が現れたら、そこにマウスポインタを当てなさい。もし単語の色が変わったら、それをクリックして用語集を参照することが出来る。（再度クリックすれば用語集は消える）

　各ステップが終わったら、ウィンドウの右下にある、右向き矢印をクリックして、次のステップに進みなさい。


2. Introduction: Designing an application
アプリケーションデザインについて

　以前のチュートリアルで簡単なアプリケーションを作った。スタックとオブジェクトを作り、そのプロパティを修正し、スクリプトを使って外見を変える方法を学んできた。

　独習の準備は整った。これまで学んだものを試し、研究するチャンスである。

　これを助けるために、研究材料となるサンプルの Revolution アプリケーションを用意した。これは様々なことを研究するのに便利である。既存の Revolution スタックを研究することによって、プロジェクトの構造や、コードスタイルや、Transcript 言語の使い方など、多くのものを得ることが出来る。


3. Example: An employee database
実例：スタッフデータベース

　このチュートリアルでは、employee（スタッフ）データベースをサンプルとして使って、少し複雑な Revolution アプリケーションをデザインする方法を考える。

　Employee Database スタックは一般的によく見られるアプリケーションである。ここにはアバウトボックスとカスタムメニューバーがあり、メニューはクロスプラットホームに対応している。そしてデータはドキュメントファイルとして別のスタックに保存される。このサンプルは Revolution を使った実際のアプリケーションデザインの多くの目的を達成している。複数の文書を扱い、Revolution の動作する任意のオペレーションシステム上で使うことが出来る。

　このようなアプリケーションをデザインする時にどんな問題に遭遇するのか、そして Employee Database ではそれをどのように解決しているのか、見て見よう。それから Application Overview でスタックの内容を調べてみよう。


4. Defining requirements
必要なことを明確にする

　家であれ、車であれ、或いはソフトウェアプログラムであれ、良いデザインはまず紙の上で始められる。

　実際の作業に入る前に、作ろうとしているものを明確にするための時間を充分に取りなさい。それは結果として開発時間の短縮に繋がる。例えば、建築中の家のベッドルームを２フィート広げるとしよう。設計士が図面を描いている時なら、壁が作られた後よりも時間と費用がずっと少なくて済むだろう。

　この設計図は、同じようなソフトウェアを作る時に大いに役立つ。アプリケーションを作るときに書いたノートの裏のメモでさえ、開発時間を短縮してくれるだろう。

　本当に役に立つプログラムを作るために、最初に、アプリケーションの用途と、そのための機能を明確にしておく必要がある。それをリストアップしてみよう....


5. Requirements for our database
このデータベースに必要なもの

　スタッフ・データベースは、各スタッフの名前、タイトルと、仕事内容を入力出来るようにしなければならない。各スタッフの写真も入れられるようになっていると便利だろう。新しいスタッフの情報を追加したり、スタッフのデータを閲覧したり、スタッフ情報の保存も出来るようにしなければならない。

　また Revolution は複数のプラットホーム向けのアプリケーションを簡単に作ることが出来るので、このデータベースもそのプラットホーム間でデータを交換出来るようにする必要がある。つまりこれから作るアプリケーションは、スタッフデータを別のファイルに保存出来ることも出来る。

　我々が対応しようとしているシステムは非常に異なっているが、Revolution の Geometry Manager と Profile Manager を利用することで、各プラットホームで使いやすいインターフェースを容易に構築することが出来る。我々はアプリケーションが持つ一般的な構成要素である、メニュー、ウィンドウ、アバウトダイアログを作る。

　これでアプリケーションの概要が決まった。 Revolution のオブジェクトモデルを使ってこれをどのように実現するのか、考えてみよう...


6. Understanding the object model
オブジェクトモデルを理解する

　開発環境のオブジェクトモデルとは、どんなオブジェクトが使えるのか、そしてオブジェクト間の関係はどのようになっているのか、を規定しているものである。 Revolution のオブジェクトモデルには、グループ、カード、スタックが含まれている。

　これまで、Revolution にはバラエティに富んだオブジェクトがあることを見てきた。アプリケーションに一般的なコントロールを簡単に加えることが出来る。ボタン、フィールド、ラジオボタン、チェックボックス、グラフィック などのオブジェクトを作ることが出来、これらをまとめたグループを作ることも出来る。ウィンドウに置くことの出来るこれらのオブジェクトのことを、一般的に「コントロール」（control）と呼ぶ。

　カードは別のタイプのオブジェクトである。カードにはコントロールを置くことが出来る。（別の言い方をすると、カードはコントロールを含むことが出来る）

　スタックは更に別のタイプの Revolution オブジェクトで、ここには複数のカードを含めることが出来る。各スタックは独立したウィンドウで、標準ウィンドウや、ダイアログボックスや、パレットのような様々なスタイルのスタックを作ることが出来る。

　各オブジェクトタイプは Revolution システムの中で独特の位置を占める。


7. The object model: Event-driven scripting
オブジェクトモデル：イベント駆動（Event-driven）型のスクリプティング

　Revolution はイベント駆動型である。これは、あなたのプログラムが起動しているあいだ、何かが起きる度に、Revolution があなたのオブジェクトにイベントを送り続けると言うことを意味する。

　例えばユーザーがスクリーン上の何かをクリックすると、Revolution はクリックされたオブジェクトに mouseUp メッセージを送る。もしそのオブジェクトが mouseUp ハンドラを持っていれば、そのハンドラの中のステートメントが実行される。

　ここで、ユーザーが mouseUp ハンドラを持たないオブジェクトをクリックしたとしよう。メッセージがボタンで処理されなかったので、Revolution はそのメッセージをボタンの乗っているカードに送る。もしカードスクリプトに mouseUp ハンドラがあればそれが実行されるが、そうでなければそのカードが属するスタックにメッセージが送られる。このようなオブジェクト間のメッセージ受け渡し経路のことを、メッセージパス（message path）と呼ぶ。


8. The object model: Inheritance
オブジェクトモデル：継承（インヘリタンス/Inheritance）

　メッセージパスの重要な一面は、いくつかのオブジェクトが同じハンドラを共用出来るということである。あるオブジェクトのスクリプトがハンドラを持っていれば、そのメッセージパスにあるオブジェクトはその機能を利用できる。例えばカードスクリプトに mouseUp ハンドラを入れておけば、そのカード上の（ mouseUp ハンドラを持たない）どのオブジェクトも、その mouseUp ハンドラを利用することが出来る。ユーザーがそれらのオブジェクトをクリックすると、まずクリックされたオブジェクトにメッセージが送られ、それからカードにパスされる。

　アプリケーションをデザインする上で大切なことは、継承がいかにスクリプティングを単純化するかを知ることである。

　例えば、同じ事をするボタンがいくつかあるとしよう。全てのボタンに同じスクリプトをコピーすることも出来るが、継承を利用すれば、カードスクリプトにそのハンドラを置くだけで済む。そうすれば、スクリプトを変更する時も、全てのボタンのスクリプトを書き換える必要はなく、１回の作業で済んでしまう。


9. The object model: Property inheritance
オブジェクトモデル：プロパティの継承

　いくつかのプロパティは継承される。オブジェクトのテキスト、カラー、パターンプロパティは、そのオブジェクトにプロパティが設定されていなければ、上位のオブジェクトから継承される。例えば textFont を設定していないボタンは、そのボタンが乗っているカードの textFont が使われる。もしカードにも textFont が設定されていなければ、メッセージパスの次の階層であるスタックの設定が適用される。 textStyle プロパティや textSize プロパティ、color プロパティも同様にして継承される。

　プロパティの継承を利用すれば、カードやスタックのプロパティを変更するだけで、全てのオブジェクトの外観を（それらのプロパティを操作することなく）変えることが出来る。この能力をうまく使えば、これから作るアプリケーションで、オブジェクトの外観を簡単に各プラットホームに合わせることが出来る。


10. Handling data files
データファイルを作る

　アプリケーションからデータを保存するにはどうしたら良いだろう？

　Revolution などで作るクロスプラットホームのアプリケーションでは、データを別ファイルに保存出来るようにする必要がある。（ Unix と Windows システムでは、アプリケーションは起動中に自分自身を書き換えることが出来ない。一貫性を持たせるために、Revolution では MacOS にも同じ制限を課している）　これは、ユーザーがスタンドアローンアプリケーションに入力したデータを保存する場合や、プログラム自身の設定などを記録する時に、それらを独立した別のファイルに保存しなければならないことを意味する。（この制限はスタックには適用されない。これは Distribution Builder で作ったスタンドアローンアプリケーションの制限である）

　データを保存するためには２つのアプローチがある。データをテキストファイルに保存する方法と、データを保存するための独立したスタックを作ることである。あなたのアプリケーションにはどちらが適しているだろうか。


11. Storing data in text files
テキストファイルにデータを保存する

　フィールドテキストのような小さなテキストデータを保存したいなら、そのデータをテキストファイルに保存するのが簡単で効率的だろう。

　URL 表現を利用すれば、put コマンドを使って、データをファイルに保存したり、読み出したりすることが出来る。ファイルはローカルディスクにあるので、URL にはファイルの名前と位置を指定する。

　例えば "Foo.txt" というファイルがあり、それが "Bat" ディスクの "Bar"フォルダに入っているとしよう。次のスクリプトを使えば、フィールドの内容をファイルに入れることが出来る：

  put field "Data" into URL "file:/Bat/Bar/Foo.txt"

  put URL "file:/Bat/Bar/Foo.txt" into field "Data"