MOSA Multi-OS Software Artists

MOSAはソフトウェア開発者を支援します

  • iPhone/iPod touch アプリ紹介
  • MOSA掲示板
  • 活動履歴
  • About MOSA(English)

MOSA Developer News［MOSADeN＝モサ伝］第163号

2005-06-07

目次

  • 「WebObjects Dev Report」　　　　　第9回　　田畑 英和
  • 藤本裕之のプログラミング夜話　#70
  • 高橋真人の「プログラミング指南」　 第68回
  • ニュース・解説　　　　　　　　　　　　　　　小池 邦人

「WebObjects Dev Report」　　第9回　　田畑 英和

　前回に引き続きモデルファイルの作成方法について解説します。実際にモデルファイルを作成するにはWebObjectsの開発環境に含まれる「EOModeler」を用います。既存のデータベースを利用する場合は、データベースの情報をもとにモデルファイルを自動生成することもできますが、今回はデータベースの作成も新規におこなう場合の手順を解説したいと思います。

モデルファイルの新規作成

　モデルファイルを新規に作成する前に、まずはあらかじめ対象となるデータベースを作成しておきます。モデルファイルを作成するときに接続先のデータベースを指定することになりますので(作成時に接続先を指定しないことも可能)、この場合あらかじめデータベース側の準備が必要になります。
　データベース側の準備が整えば次にEOModelerでモデルファイルを新規に作成するわけですが、現在のEOFはデータソースとしてJDBC接続によるRDB、もしくはJNDIを用いたLDAPのようなディレクトリサービスをサポートしています。新規にモデルファイルを作成する場合、まずはデータソースへの接続方法としてJDBCかJNDI(あるいは接続方法の指定なし)を選択します。
　JDBCを選択した場合、JDBCへの接続情報を指定しますが、こちらは前回紹介しましたJDBCのURLやパスワードの情報になります。あらかじめ「JobMatch」という名前のデータベースを作成していたとすると、URLは以下の形式になります。

・JDBCのURL(OpenBaseの場合)
jdbc:openbase://127.0.0.1/JobMatch

　JDBCの接続情報を入力した後は、EOModelerのWizardがこれから作成するモデルファイルのパラメータを確認しますが、新規にデータベースも作成する場合は特に指定するパラメータもありませんので、JDBCの接続情報を指定しただけで新規のモデルファイルを作成することができます。
　モデルを新規に作成した直後はまだファイルとして保存されていませんのでとりあえず名前を付けてファイルを保存します。モデルファイルのファイル名は例えばデータベース名と合わせて「JobMatch.eomodeld」などとしておくのがよいでしょう

Entityの追加

　データベース上には一般的に複数のテーブルを作成することができます。モデルファイルではオブジェクトとデータベースとのマッピング情報を定義していきますが、まずはテーブルレベルでのマッピングをおこないます。
　データベース側でのテーブルに相当するものをEOF上では”Entity”と呼んでおり、このEntityはプログラム上ではクラスに相当します。EntityのマッピングをおこなうにはEOModeler上でEntityを追加し、Entity名(Name)とデータベース名(Table)を入力します。このとき自動的に”EOGenericRecord”がクラス名として設定されますが、これはEOFが提供しているクラスであり単純なデータアクセスをおこなうだけであればこのままでもかまいません。ですが、独自のビジネスロジックを追加していく場合にはビジネスロジックを実装するクラス名を設定しておきます。ここで設定したクラス名をもとにEOModelerは自動的にクラスファイルの生成をおこないます。

・Entityの例
Name = JMUser, Table = USER, Class Name = JMUser

Attributeの追加

　Entityを追加しただけの状態でモデルファイルを保存しようとすると次のようなメッセージが表示されます。

“Entity JMUser does not have a primary key defined”

　EOModelerはモデルファイルの保存時に自動的にモデルファイルをチェックしますが、モデルの内容に不整合があった場合にはこのようにエラーメッセージが表示されます。今回のエラーメッセージは、本来Entity上に必要なプライマリキーの設定が存在しないといった内容になります。
　Entityを追加した後は、Entity内にAttributeの追加をおこないます。データベースのテーブルには一般的に複数のカラムが存在しますが、Entityとテーブルをマッピングしたのと同様にAttributeはカラムとマッピングします。
　Entityのマッピングをおこなったさいには名前をマッピングしただけでしたが、Attributeのマッピングをおこなった場合には型情報のマッピングもおこないます。データベース上の型とプログラム上の型はそれぞれ定義が異なっていますので、プログラム上での各データの型をデータベース上の各カラムの型とマッピングします。さらに、追加したAttibuteにはプライマリキーの属性やNullを許可するかどうかの属性などを指定することができます。

　さて、今回はモデルの作成の基本的なところをご紹介しました。この記事が配信されるころにはすでにWWDCが開催されているかと思いますが、今年は基調講演でどのような発表があるのでしょうか。それではまた次回

藤本裕之のプログラミング夜話　#70

　前回に引き続き、NSViewの「描かれ方」を詳しく追ってみる。その目的は、とかく混同されがち、というかそのフルマイが誤解されがちな以下のメッセージ群の関係をきっちり確認することである。

　-(void) setNeedsDisplay:(BOOL)flag;
　-(void) displayIfNeeded;
　-(void) display;
　-(void) drawRect;

　今ドキュメントを調べてみたら遂にCarbonにおいても「Unsupported」になっていたが、かつて「InvalRect()」というAPIがあった。正確には

　void InvalRect (const Rect* badRecr);

てなもんで、これが何をするモノだったかというと、指定された矩形領域を「ココは描きなおされなければならないぞリスト」に加えていたわけである。重なり合ったウィンドウの上のヤツが動くと、下のウィンドウの今まで隠されて見えなかった部分が見えるようになる。見えるようになるからには描かねばならない。描かねばならないからって委細構わず闇雲に描いていい道理はないので（つうかたいへん非効率なので）、とりあえすはこのAPIを呼んで「ココは描きなおされなければあきまへんで」と覚えておき、次の描画タイミングでババっと一気に描くちうことをやってたわけだ。

　前回チェックボックスの描き替えについてみたように、CocoaのNSView、およびそのサブクラスにおいてこのInvalRectと同じ役割を担っているのが「setNeedsDisplay:」ということになる（正確にはよりInvalRect()に近い「setNeedsDisplayInRect:」ちうのがあるわけだが話を簡単にするためにここでは触れない）。これを呼んでおけば、現在進行中のイベント処理が終わった時点で各ウィンドウに「displayIfNeeded:」が送られ、それはまたそのサブビューたちに「displayIfNeeded:」を送り、という形で必要な描画を完了させることができる。ここまではよろしいか。

　ではココで問題である。それぢゃ「display」というメソッドは何のためにあるのでしょう？　ドキュメントによればこのメソッドは「レシーバーおよびそのサブビューを可能なかぎりDisplayする」モノである。「Display」を「描画」と訳していいのかどうかは微妙なところだが言わんとすることは分かるよね？　つまりこいつは「setNeedsDisplay:」によって「描き替えが必要ですよリスト」に載せられていようといまいと委細構わずそのオブジェクトを描いちゃうのである。早い話が（早くないか）上のInvalRect()の説明で「いい道理りはない」と断じたトコロの「闇雲なる描画」をするためにあるとしか言えないではないの、これ。

　試しにこういう実験をやってみた。テキトーなNSViewのサブクラスを作り、NSResponderの「keyDown:」をオーバーライドする。キーはなんでもいいが、例えば右向き矢印だったら

　[self setNeedsDisplay:YES];

左だったら

　[self display];

を呼ぶ。おのおのの前後に「いまこいつを呼んだぜ」「戻ってきたぜ」てなプリント文を配し、このオブジェクトの drawRect: にも「オレが呼ばれたぜ」というプリント文をかませる。右矢印を押すと、コンソールにプリントされる順番は「いまsetNeedsDisplayを呼んだ」「setNeedsDisplayから戻ってきた」「drawRectが呼ばれた」となるが、これが左だと「displayを呼んだ」「drawRectが呼ばれた」「displayから戻ってきた」となる。ね、確かにdisplay はイラチというか速戦即決というか、その場でdrawRect: を呼んぢゃうのである。が、こんなのをホイホイ呼んでたら描画のオーバーヘッドになること請け合いだ（これが請け合いでないならsetNeedsDisplay: なんて仕組みを作る必要はないんだから）。それではこの display というのはナンのためにありどんな時に使うのが正しいのでしょうか、というのが次回のお話しになる。ほんでは。
（2005_05_31）

高橋真人の「プログラミング指南」第68回

UNIXとしてのMac OS X

〜Perlについて(14)〜

　こんにちは、高橋真人です。
　では早速まいりましょう。miをダウンロードしインストールしたら、新規ドキュメントを開いて適当に文字を入力してください。（具体的に何を入力するかについては、このあとの解説を読んで実験するのにふさわしい文字列を適宜選んでください）
　次に「検索」メニューから「検索・置換」を選んで検索ダイアログを開きます。ダイアログの中央やや下寄りに並んでいるチェックボックスで、「正規表現検索」と「巡回」にチェックを入れます。それ以外の項目はそのままです。

　それでは、最初に「検索文字列：」フィールドに「ABC」（カギカッコは付けない。以下同様）と入力して、リターン（検索ダイアログがアクティブな場合）、もしくはコマンド+G（ドキュメントウインドウがアクティブな場合）を押してみてください。
　エディターウインドウに入力された文字列の中にABCの文字並びがあれば、反転され、検索されたことが分かります。（ABCがなければ何も起こりません）さらに連続してコマンド+Gを押すと、条件に合致する文字並びがある限り、順に反転されるのが分かります。

　おめでとうございます。
　これであなたは初めての正規表現による検索に成功しました。

　なぁーんて使い古されたプログラミング入門書のセリフみたいなことを申しましたが（笑）、申した中身は嘘じゃあありません。
　「ただ単に文字列を検索しただけなのに」と訝しげな方もおいででしょうが、実は「ただの文字列」も、れっきとした正規表現なのです。ABCという文字並びは、正規表現として解釈すると、「最初に半角大文字の（以下同様）A、続いてB、最後にCが連続して現れる『パターン』である」ということになります。
　この「パターン」という言葉、昨今ではオブジェクト指向において使われることが多く、「分かるようで分からない言葉」の一つかもしれませんが、正規表現においては一般に使われる言葉です。正規表現による検索のことを「パターンマッチング」と呼ぶこともあるので憶えておきましょう。（「検索」という言葉を「文字列照合」という少し硬めの表現に言い替えてみるとイメージが結び付きやすいのでは？）

　さて、もちろん単純な文字列だけならば、わざわざ正規表現を使って検索するまでもありませんから、いくつかの例を見ながら正規表現によってどのような検索の幅が出てくるのかを見ていきましょう。

　まずはごく簡単な例として、ABCに対して「Aが小文字でもよい」という条件を付けてみます。つまり、検索対象は「A（大文字か小文字）、続いてB、C」となります。
　正規表現が「文字の並びを表す表現」であるならば、「Aの大文字か小文字」を表す表現はどうなるでしょうか。

[aA]

　これが、正規表現における「aもしくはA」です。この角カッコ（ブラケット）で囲ったものを正規表現では「文字クラス」と呼び、中に羅列されている文字のうちのどれか1文字に該当する文字とマッチします。
　文字クラスにはいくつかの注意点があります。
　まず、繰り返しになりますが、ブラケットの中に文字がいくつ並んでいても、これ全体で「1文字を表している」ということです。あくまでヒットするのは1文字だけです。初心者のうちは混乱する人が多いので注意しましょう。

　また、文字クラス表現の中において特殊な役割を持つ文字がいくつか存在します。まずは^です。^という記号は、通常の正規表現においては文字列または行の先頭を意味する記号（いずれ説明します）ですが、文字クラスの中で使われると全く違う役割を持ち、「除外」という意味になります。たとえば、

[^aA]

という表現は、「（すべての文字の中で）aとAを除外したものすべて」を意味します。もちろんこの表現は1つの文字とマッチしますが、検索で用いられた場合、最初に見つかった文字がaでもAでもなければ、その文字にヒットし、逆に最初の文字がaかAだった場合にはヒットせずに、順番に先を見ていって、aでもAでもない文字が見つかった時点でヒットするのです。

　ところで、^の文字が文字クラスの先頭、つまり開きのブラケットの直後に来ない場合には、^は特殊性を失いただの^という文字を意味します。従って検索したい対象が「aかAか^」のいずれか1文字の場合、^は必ず2番目以降に記述しなければなりません。

[a^A]
か
[aA^]

という具合です。
　正規表現の正式な位置付けでは、先頭に^のある文字クラスについては「否定文字クラス」という別物の扱いのようです。

　文字クラスの中で特殊な意味を持つ記号には、あと-があります。これは範囲を表す役割を持ちます。つまり、

[ABCDEFGHIJKLMNOPQRSTUVWXYZ]

と書く代わりに、

[A-Z]

と書いても同様な意味になりますし、また、

[ABCXYZ]

という同等の表現として、

[A-CX-Z]

と書くこともできるわけです。（カンマとかを入れないように注意）

　さて、文字クラスについて少し深く見てみましたが、話を戻しましょう。「ABC、ただしAは小文字でも可」を表す正規表現は、

[aA]BC

となります。もちろん、[Aa]BCと書いてもOKです。

ニュース・解説

今週の解説担当:小池邦人

Carbon ドキュメント & サンプル ＆ SDK ナビゲーション（2005/6/3）

【開発環境】

いよいよWWDC2005が開幕します。今年は、直前にTiger（Mac OS X 10.4）が販売開始されたことで、そのフィードバックとハンズオン（Apple社の技術者と共にソフトやハードに最新技術を実装をする実習みたいなもの）が中心になると予想されています。また、事前に発表されているカンファレンスセッションの内容や催し案内を眺めても、そうした雰囲気になるのは間違いなさそうです。ある意味、ちょっと新味に欠けるWWDCになるかもしれません。まさか、Mac OS Xの次期コードネーム（みんな興味あり）や、その内容の一部が紹介されるなんてことはないと思いますが（笑）、ハードだけでなく、開発環境やソフト方面でも何か大ネタが用意されているのを期待したいところです。

そうした中、ほんのちょっとだけ私が期待しているのが、64bit化されたCarbonとCocoa Frameworkの発表です。Tigerでは64bitアプリケーションの開発と起動が可能になりました。しかし、それはあくまでもグラフィカルユーザインターフェースを持たない（CarbonもCocoaも使わない）アプリケーションのみに限定されます。確かに、32bitアドレッシングではアクセスできないような大容量データを、64bit化した別プロセスにより管理するといった作業は可能です。しかし、そうした大量データをユーザインターフェースを用いてリアタイム処理したい場合には、その制御や描画に関わるFrameworkが64bit化されていなければ不可能となります。私が関わっているVoxelデータの処理アプリケーションなどが、そうした状況に置かれている典型的な代物です。ところで、64bit Carbonの登場時には間違いなくQuickDrawとはサヨナラかもしれません…。その時が近づくのが嬉しいやら寂しいやら（笑）。

Mac OS X 10.4における64bitアプリケーションの動作環境や開発については、以下のドキュメントを参照してみてください。

「64-Bit Transition Guide」

http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/index.html

【テクニカルドキュメント】

前回から6月3日の期間中、AppleのDocumentationサイトには新規ドキュメントがひとつも登録されませんでした。年に数回あるかないかの現象ですが、WWDC直前のこの時期はいつものことです。今頃、Apple社の技術者達はKeynoteによるプレゼン作りで大忙しでしょう（笑）。

http://developer.apple.com/appleapplications/ardsql.html

前回から6月3日の期間中、新規のテクニカルノートはひとつも登録されませんでしたが、新規テクニカルQ&Aの方は2つ登録されました。QA1416の方については、前号の木下さんの解説も参考にしてください。

QA1242「Developing for VFS」
QA1416「Specifiying if the CPU or the GPU should be used for rendering」

http://developer.apple.com/technicalqas/index-rev-date.html

【サンプルソースコード】

前回から6月3日の期間中、Apple社のSample Codeサイトには、新しいサンプルソースコードがひとつも登録されませんでした。

http://developer.apple.com/samplecode/index-rev-date.html

【デベロップメント SDK】

前回から6月3日の期間中、Apple社のSDKサイトには新しいSDKがひとつも登録されませんでした。

http://developer.apple.com/sdk/

MOSAからのお知らせと編集後記は割愛します

MOSA Developer News　　　略称［MOSADeN＝モサ伝］
Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
このメールの再配信、および掲載された記事の無断転載を禁じます。
特定非営利活動法人MOSA
Copyright (C)2005 MOSA. All rights reserved.