MOSA Developer News［MOSADeN＝モサ伝］第168号
2005-07-19
目次
- 「WebObjects Dev Report」 第14回 田畑 英和
- 小池邦人の「Carbon API 徒然草」
- SqueakではじめるSmalltalk入門 第43回 鷲見 正人
- ニュース・解説 木下 誠
「WebObjects Dev Report」 第14回 田畑 英和
今回は、前回解説しきれなかった多対多のRelationを解説したいと思います。対1(to-One)と対多(to-Many)のRelationはすでに紹介しましたが、これだけでは表現できないデータ構造もあります。たとえばビジネスマッチングシステムにユーザのプロファイルを登録するときに、ユーザごとに得意なプログラミング言語も登録できるようにするとしましょう。
このとき、登録可能なプログラミング言語用のEntity(ProgLang)を追加してからMOSAUserとRelationを設定するとします。複数のプログラミング言語をマスターしている方もいらっしゃるでしょうから、1人のユーザに対して複数のプログラミング言語が選択できる必要があります。
ですが、単純にMOSAUserからProgLangに対して対多のRelationを設定してしまいますと、MOSAUserのプライマリーキーをProgLangに外部キーとして登録することになり、ProgLangからみるとMOSAUserに対して対1のRelationしか設定できなくなります。つまりあるプログラミング言語はたった1人のユーザにしか設定できなくなります。これではObjective-Cが使えるのはSさんだけ、Javaが使えるのはTさんだけ、となってしまいますが実際には1つのプログラミング言語は複数のユーザに設定できるようにしなければなりません。
つまり、MOSAUserからProgLang、ProgLangからMOSAUserの両方について対多のRelationを設定する必要があるということです。このようなRelationが多対多ということになりますが、ここで問題になるのが外部キーをどのように扱うかです。2つあるEntityのどちらかのプライマリキーをもう片方の外部キーとして扱うと、Entityが2つだけでは両方で対多のRelationを設定することができません。
両方のEntityのプライマリーキーをそれぞれ外部キーとして扱う必要があるわけですが、キーを管理するためのEntityを1つ追加することによって対応が可能になります。
そこで具体的にどうするかですが、分かりやすくするためにまずは簡単な例を考えてみましょう。まずユーザSからUまで3人のユーザが存在し、それぞれ次のようなプライマリーキーが割り当てられ、プログラミング言語としては3つの言語が管理されていたとしましょう。
・ユーザ(プライマリーキー)
ユーザS(1)
ユーザT(2)
ユーザU(3)
・プログラミング言語(プライマリーキー)
Objective-C(10)
Java(11)
Ruby(12)
各ユーザごとに複数のプログラミング言語を設定するには、キーを管理する3つ目のEntityを用意し、ユーザとプログラミング言語のEntityのそれぞれのプライマリーキーの組み合わせを設定します。つまり次のようになります。
・3つ目のEntity
1, 10 <- ユーザSとObjective-C
1, 11 <- ユーザSとJava
1, 12 <- ユーザSとRuby
2, 11 <- ユーザTとJava
3, 10 <- ユーザUとObjective-C
3, 12 <- ユーザUとRuby
ユーザとプログラミング言語のEntityにおけるプライマリーキーの組み合わせが3つ目のEntityに登録されています。このとき3つ目のEntityには2つのキーを登録できるように、2つのAttributeを追加しておきます。ではこのとき3つ目のEntityのプライマリーキーをどのように設定するかですが、2つのキーの組み合わせは3つ目のEntity内ではかならずユニークになります。ですので、3つ目のEntityに追加した2つのAttributeをそれぞれプライマリーキーとして設定することにより、Entity内での各レコードをユニークに識別できるようになります。このようにプライマリーキーは必ずしもEntity内で1つだけではなく、複数存在する場合もあります。
多対多の関係をもったRelationをモデル上に作成する方法ですが、基本的には1つEntityを追加し、双方のEntityのキーを管理すれば良いことになります。ですがEOModelerには多対多のRelationを自動的に作成する機能がありますので、こちらを紹介しておきましょう。Relationを設定したい2つのEntityを選択した状態で、「Property」メニューから「Join in Many-to-Many」を実行すると、自動的に3つ目のEntityおよびRelationを自動的に作成してくれます。自動的に作成されたEntityやRelationの名前は必要に応じて変更するとして、これで簡単に多対多のRelationを作成することができます。
WebObjectsに付属するサンプルのモデルファイルにも、多対多のRelationが含まれていますので、そちらも参考にしていただければと思います。
・モデルファイルのサンプル
/Developer/Examples/JavaWebObjects/Frameworks/JavaBusinessLogic/
Movies.eomodeld
小池邦人のCarbon API 徒然草
Carbon API 徒然草（2005/07/15）
〜 ドラッグ＆ドロップの活用（その6） 〜
今回は、アプリケーションからFinderなどにファイル情報をドラッグ＆ドロップする時、どのようにドラッグアイテムを作成したら良いのかを調べてみます。具体的には、ドラッグアイテムとして渡すことになる、HFSFlavor構造体と、PromiseHFSFlavor構造体の使い分けの解説です。
まず最初に紹介するのが、Finderや他のアプリケーション（ワープロや画像編集ソフトなど）にファイル情報を渡す時に用いられるHFSFlavor構造体です。ここで注目すべきは、ファイルデータ（ファイルの中身）自体を渡すのではなく、ファイルタイプ、クリエータ、Finderフラグ、FSSpec構造体といったファイル情報を渡すという点です。例えば、ワープロがドラッグ＆ドロップによりファイル情報を受け取ると、そのタイプからテキストなのか？ 画像なのか？画像であればどんな種類なのか？ を判断してから、FSSpec構造体を参照してデータを読み込み、作業用ウィンドウのドロップされた位置にそれを張り込むことになります。
struct HFSFlavor {
OSType fileType; // ファイルタイプ
OSType fileCreator; // ファイルクリエータ
UInt16 fdFlags; // Finderフラグ
FSSpec fileSpec; // FSSpec構造体
};
以下のcreateDataMyDrag()ルーチンは、HFSFlavor構造体をAddDragItemFlavor()でドラッグアイテムとして登録しています。登録すべきファイルのFSSpec構造体は、自作ルーチンのgetMyTargetFSSpec()で得ていますが、この部分を適切な処理に差し替えれば、そのまま汎用ルーチンとして利用することが出来ます。ターゲットファイルのファイルタイプ、クリエータ、Finderフラグについては、FSpGetFInfo()を使えば得ることが出来ます。
short createDataMyDrag( WindowPtr window,ControlRef chd,DragReference dref )
{
short ret=1;
FInfo info;
FSSpec fsc;
long len;
HFSFlavor hfs;
if( ! getMyTargetFSSpec( window,&fsc ) ) // ドロップファイルのFSSpecを得る
{ // （自作ルーチン）
FSpGetFInfo( &fsc,&info ); // ファイルのFinder情報を得る
hfs.fileType=info.fdType; // ファイルタイプ
hfs.fileCreator=info.fdCreator; // ファイルクリエータ
hfs.fdFlags=info.fdFlags; // Finderフラグ
hfs.fileSpec=fsc; // 目的ファイルのFSSpec構造体
len=sizeof( HFSFlavor ); // HFSFlavor構造体のサイズ
ret=AddDragItemFlavor( dref,(ItemReference)1,kDragFlavorTypeHFS,
(Ptr)&hfs,len,0L );
// ドラッグアイテムに加える
}
return( ret );
}
Finderは、上記のドラッグアイテムを受け取ると、いったいどんな処理を実行するのでしょうか？ それを試すのには、Adobe PhotoshopなどでJPEG画像をオープンし、ウィンドウタイトルに表示されるプロキシアイコンをデスクトップ上にドラッグ＆ドロップしてみてください。対象となるJPEGファイルのアイコンは、ドロップされたデスクトップ位置へと移動させられます。また、オプションキーを押しながら実行すると、そのファイルは複製され、オプション＋コマンドキーを押しながらだと、Aliasファイルが作成されることが分かります。つまり、Finder上でアイコンをマウス操作するのとまったく同じ処理を実行しているわけです。
それでは、ドラッグ＆ドロップでファイル情報を渡すのではなく、ファイルデータ（ファイルの中身）そのものを、別アプリケーションに渡したい時にはどうしたら良いのでしょうか？ 普通に考えれば、データそのものをドラッグアイテムに追加してしまえば良いわけですが、ファイル容量が膨大（数100Mとか）であると、そのドラッグアイテムを作成するのに相当な時間がかかることになります。すると、ユーザが対象物をマウスドラッグしようとしても、それがマウス移動に追随できない状況が発生し、ドラッグ＆ドロップの操作感を大きく損ねてしまいます。また、作業用メモリが不足し、処理を継続できない可能性も出てきます。
そこで、Drag Managerには、実際のデータの受け渡しを、ドラッグ開始時ではなくドロップ時に行う仕組みが備わっています。つまり、ドロップ時であれば、少々時間がかかる処理であっても、ユーザの操作感は損なわれないわけです。この仕組みを用いると、ドラッグ開始時に大量データをドラッグアイテムに追加する処理を省略することができます。この時にドラッグアイテムとして利用するのが、以下のPromiseHFSFlavor構造体です。
struct PromiseHFSFlavor {
OSType fileType; // ファイルタイプ
OSType fileCreator; // ファイルクリエータ
UInt16 fdFlags; // Finderフラグ
FlavorType promisedFlavor; // 予約アイテムタイプ
}
今回は、Finder上のドロップした位置に、ドラッグしてきたファイルの複製を作成してみます。また、複製されたファイルは、こちらで指定した文字列により名称変更がなされるとします。以下のcreateDataMyDrag()ルーチンで、PromiseHFSFlavor構造体をドラッグアイテムとして登録しています。加えて、オリジナルファイルのFSSpec構造体、名称変更用のパスカル文字列も追加します。そして最後に、アイテムタイプがkDragPromisedFlavorで、データが何も含まれていないドラッグアイテムをひとつ追加します。
short createDataMyDrag( WindowPtr window,ControlRef chd,DragReference dref )
{
short ret=1;
FInfo info;
Str255 name;
FSSpec fsc;
PromiseHFSFlavor phf;
if( ! getDuplicatetFSSpec( window,&fsc,name ) ) // 複製元ファイルのFSSpecと
{ // 複製先名称を得る（自作）
FSpGetFInfo( &fsc,&info ); // Finder情報を得る
phf.fileType=info.fdType; // ファイルタイプ
phf.fileCreator=info.fdCreator; // ファイルクリエータ
phf.fdFlags=info.fdFlags; // Finderフラグ
phf.promisedFlavor=kDragPromisedFlavor; // kDragPromisedFlavorタイプ
AddDragItemFlavor( dref,(ItemReference)1,'str ',(Ptr)&name,
sizeof(Str255),0 );
// 名称変更用のパスカル文字列を追加
AddDragItemFlavor( dref,(ItemReference)1,'fsc ',(Ptr)&fsc,
sizeof(FSSpec),0 );
// 元ファイルのFSSpec構造体を追加
AddDragItemFlavor( dref,(ItemReference)1,kDragFlavorTypePromiseHFS,
(Ptr)&phf,sizeof(PromiseHFSFlavor),0 );
// PromiseHFSFlavor構造体を追加
ret=AddDragItemFlavor( dref,(ItemReference)1,kDragPromisedFlavor,
NULL,0,0 );
// kDragPromisedFlavorタイプを追加
}
return( ret );
}
次回は、今回のファイル複製処理の続きです。以前解説したstartMyDrag()の中で登録しておいたsendDataMyDrag()ルーチンについて詳しく解説します。ドラッグアイテムに追加されたPromiseHFSFlavor構造体やその他の情報は、このルーチンの中で解析されてファイル複製に利用されることになります。
つづく
SqueakではじめるSmalltalk入門 第43回 鷲見正人
本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。前回までにファイルストリームの扱い方について触れたので、それにからめて、簡易ファイラである「ファイル・リスト」や、オブジェクトの“ファイル化”やユーザー間でのやりとりの方法について、しばらく順を追って解説してゆきたいと思います。
MacのFinderやWindowsのExplorerほど高機能なものではありませんが、Smalltalkシステムにも「ファイル・リスト（file list）」と呼ばれる簡易ファイラがあります。ディレクトリの閲覧や作成、ファイルやディレクトリの削除、ファイルの名称変更などが可能です。加えて、ファイル内容の確認やその内容の編集など、テキストエディタのような機能も提供します。
SqueakNihongo7でファイル・リストは、デスクトップメニューから「開く…」→「ファイル・リスト」で呼び出すことができます。
[fig.A]ファイル・リスト
http://squab.no-ip.com:8080/mosaren/uploads/43a.png
もちろんメッセージ式のdo it (Cmd + D)でも起動可能です。
FileList2 morphicView openInWorld
なお、クラス名の最後に“2”とあるのは、以前のバージョンである「FileList」の存在を意味します。この“旧バージョン”のファイル・リストも次の式のdo itで起動して使用することができます。
FileList openAsMorph openInWorld
[fig.B]旧バージョンのファイル・リスト
http://squab.no-ip.com:8080/mosaren/uploads/43b.png
新バージョンといってもFileList2はFileListのサブクラスに過ぎません。文字通り、FileListの機能を継承し、それに拡張を施しただけの存在で、現時点ではまだ、FileListに置き換わるほどの“地位”を得ているわけではありません。将来、FileListがFileList2に踏みつぶされて機能しなくなり、さいごにはFileList2に吸収され消滅することもあるかもしれません。が、経験上それはかなり先の話になりそうです。なぜって、SqueakにはまだALTO時代のGUIフレームワーク（MVC）が生き残っていて、必要ならいつでも目覚めさせ、利用できるようになっているくらいなんですから！（デスクトップメニュー →「開く…」→「MVCプロジェクト」）
それでは簡単に、（新バージョンの）ファイル・リストの機能を紹介してゆきましょう。
ファイル・リストのウインドウは、おなじみのシステム・ブラウザやインスペクタと同様、機能を受け持つペイン（枠）で区切られています。おおまかには、上のペイン群はディレクトリやファイルの閲覧、下のペインは上のペインで指定したディレクトリやファイルの内容を表示するためのものです。なお、選択されたファイルがテキストファイルなら下のペインで編集、保存も可能です。
上のペインはさらに左右のペインに分けられていて、左手がディレクトリ一覧、右手が左のペインで選択したディレクトリ内のファイル一覧に使われます。最上段のペイン左側の入力欄は、ファイル名のパターンでファイルの一覧を絞り込むためのものです。デフォルトでは全パターン「*」になっていますが、たとえばこれを「*.txt」などと変更後accept (Cmd + S)すれば、テキストファイルだけに限定して一覧できます。そのすぐ右側に並ぶボタン群は、ファイル一覧ペインの黄ボタンメニューでよく使う項目をボタン化して使いやすくしたものです。起動時には「name」「日付」「size」となっていて、ファイル一覧の並び順を変更できます（デフォルトは日付順）。Smalltalk関係のファイル（.st、.cs）や画像ファイルなどを選択すると、対応して、このペインのボタンが増えます。
[fig.C]Smalltalkコードを収めたファイルを選択したとき
http://squab.no-ip.com:8080/mosaren/uploads/43c.png
[fig.D]画像ファイルを選択したとき
http://squab.no-ip.com:8080/mosaren/uploads/43d.png
たとえば、画像を選択したときは「読み込み」「開く」「background」という3つのボタンが追加されます。「読み込み」は画像ライブラリへの画像の登録、「開く」はその画像をオブジェクトとしてデスクトップに呼び出すとき、「background」はデスクトップ画像を選択画像に変更の際に使用します。いずれもファイル一覧ペインの黄ボタンメニューからも実行可能です。（それぞれ「画像をImageImportsに読み込みます」、「open graphic in a window」、「画像を背景として使います」に相当）
「画像ライブラリ」とは、デスクトップメニューの「ヘルプ…」→「画像ライブラリ」で呼び出すことができるMac OS 9時代のスクラップブック（ただし画像専用）のようなソフトです。
[fig.E]画像ライブラリ
http://squab.no-ip.com:8080/mosaren/uploads/43e.png
画像ライブラリから興味のある画像を取り出すには、まず、「Prev」「Next」ボタンでその画像を表示させ、つづけて「Prev」のすぐ左手のメニューアイコンをクリックしてポップアップするメニューから「hand me one」を選択します。
なお、画像をSquaekシステム内に取り込む方法としては、このようにファイル・リストを使うほかに、Finderから画像ファイルのアイコンをSqueakのウインドウにドロップインする手軽な方法も用意されています。
デスクトップに現われた画像オブジェクトは、不要ならば、Cmd-クリックで選択後、×ボタンをクリックすることで消去可能です（他に、右手中央の鉛筆ボタンでペイントツールによる加筆も可）。また、バックグラウンド画像を変更してしまった際には、デスクトップメニューの「元にもどす “背景画像の設定”」で元に戻すことができます。ファイル・リストとは直接関係ありませんが、以上、参考まで。
次回はファイル・リストの簡易エディタ機能について紹介します。
バックナンバー：
http://squab.no-ip.com:8080/mosaren/
ニュース・解説
今週の解説担当:木下 誠
———————————————————————-
Universal Binary Programming Guidelinesの日本語訳が登場
———————————————————————-
IntelとPowerPCチップ両対応のバイナリを作るためのドキュメント、「Universal Binary Programming Guidelines」の日本語訳が、アップルのサイトで公開されました。
このドキュメントには、チップのアーキテクチャの差、エンディアンの違いの解説、コンパイラの設定など、Intelチップ用のプログラムのための技術情報が詰まっています。Intelへの移行作業を行っている方はもちろん、これから新規にプログラムを書く方も必読です。あらかじめ、プログラムをできるだけエンディアンフリーにしておくことが大切になります。将来何が起こるか、まったく予想がつきませんからね。
素早い日本語訳の登場は、評価したいと思います。この調子で、他のドキュメントも提供されると、うれしいのですが。
Universal Binaryプログラミングガイド
http://developer.apple.com/ja/documentation/MacOSX/Conceptual/universal_binary/
———————————————————————-
Cocoa-Javaの終焉？
———————————————————————-
先週の小池さんのニュースでもありましたように「Cocoa-Java Integration Guide」がアップデートされましが、その中に「10.4から後のCoocaの機能は、Cocoa-Javaに追加されない」という記述があります。これは、Cocoa-Javaのサポートが、10.4までで終了すると受け取れます。
Cocoaプログラミングの窓口を広げるために導入されたJava APIでしたが、ここでおしまいになるようです。Javaの特徴として、プラットフォーム非依存や、静的な型を持つ傾向がありましたが、このあたりがCocoaとの相性が悪かったのかもしれません。
今後、Cocoaの新規APIは、Objective-Cのみになるようです。もっとも、10.4までのCocoa-Javaでも、かなりのアプリケーションが作れるとは思います。
Cocoa-Java Integration Guide
http://developer.apple.com/documentation/index.html
———————————————————————-
UTIの解説ドキュメント
———————————————————————-
UTI (Uniform Type Identifiers)の使い方を解説したドキュメント、「Simplifying Data Handling with Uniform Type Identifiers」が公開されました。
UTIは、ファイルの種類を特定する新しい手段として、導入されました。拡張子、MIMEタイプ、OSタイプなどから、統一的な新しいファイルタイプUTIが決定されます。UTIは、ドキュメントを扱うアプリケーションや、Spotlightなどで使われています。
Simplifying Data Handling with Uniform Type Identifiers
http://developer.apple.com/macosx/uniformtypeidentifiers.html
———————————————————————-
QTKitのFAQ
———————————————————————-
CocoaでQuickTimeを取り扱うためのフレームワーク、QTKitのTechnical Note、「QTKit Frequently Asked Questions」が公開されていました。様々な質問が取り上げられています。
現在のQTKitは、基本的に「再生」に関する機能しかなく、高度な編集や作成、録音といった機能はありません。このドキュメントでは、将来のバージョンで、ムービーにトラックを追加したり、空のムービーを作成する機能が追加されるだろう、と述べられています。
TN2138: QTKit Frequently Asked Questions
http://developer.apple.com/technotes/tn2005/tn2138.html
———————————————————————-
Enhanced Podcast作成のためのツール
———————————————————————-
7/15日に、MOSA主催による「Podcastingセミナー」が開かれましたが、そこでEnhanced Podcastingを作成するためのツール、ChapterToolが紹介されました。ChpaterToolは、Appleが配布している、AACファイルにchapterを埋め込むためのツールです。
ダウンロードするには、iTunes 4.9で、iTunes Music Storeに行きます。Podcastsの項目から、Publish Podcastsを選び、そこにある「Learn more about podcasting on iTunes」をクリックします。すると、ダウンロードページが表れます。
このツールを利用することで、iTunes上で音声と画像を同期して再生することができるようになります。
MOSAからのお知らせと編集後記は割愛します
Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
このメールの再配信、および掲載された記事の無断転載を禁じます。
特定非営利活動法人MOSA
Copyright (C)2005 MOSA. All rights reserved.