Monthly Archives: September 2013

FileMaker ServerのAdmin Console起動のファイルの入手すらできない場合

OS XでFileMaker ServerのAdmin Console接続の続報です。なんとかうまくセットアップができたとしても、そのうちあれこれやっていると、16000番ポートにつなぐとこれになることがあります。もちろん、Javaのインストールはすでにやってあってもこれが出てしまうとします。そうなると、admin_console_webstart.jnlpというファイルのダウンロードができません。

スクリーンショット 2013-09-28 0.44.01

そのようなときには、ブラウザのアドレス欄に以下のようなURLを入れます。これで、admin_console_webstart.jnlpが入手できます。

http://ホスト名:16000/admin_console_webstart.jnlp

OS XでFileMaker ServerのAdmin Console接続

JavaVMをAppleがリリースしなくなり、OS XのJavaは混沌としてしまっていますが、FileMaker Serverを使うにはどうしても避けて通れません。FMS自体を動かすためのJavaのバージョンについてはFileMakerのサイトにいろいろな情報が掲載されていますが、サーバ管理ツールのAdmin Consoleについてもバージョンの混在で訳が分からなくなりつつあります。

OS Xのメンテナンスをどうやってきたかによって多分動作は違うと思いますが、私のメインマシンは以下のようにどうしようもない状態になりました。

  • ログイン時に作ったアプリケーションでは起動しなくなった。
  • 16000番ポートに接続して表示されるページのアイコンをクリックしても、Admin Consoleは表示されなくなった。admin_console_webstart.jnlpがダウンロードされるだけ。
  • サーバからadmin_console_webstart.jnlpというファイルがダウンロードできれば、それを右クリックして、「Java Web Start」を選択すると、なんとか起動できるようになった。

3つ目の方法でなんとか凌ぐということもできるのですが、なんか不便です。また、admin_console_webstart.jnlpに接続先情報が組み込まれているためと思われますが、サーバごとにkのファイルを残しておかないといけません。そんなわけで、コマンドラインで管理したりとか、だんだんダークな世界に入りつつあり、なんとかできないのかと思ったのですが、Automaterでアプリケーションを作ればいいじゃんということに気付きました。こんなのを作ります。

fig2

このワークフローは、Automaterで新しくウインドウを作ったときに「アプリケーション」を選択します。最初の「指定されたFinder項目を取得」は、admin_console_webstart.jnlpファイルをウインドウ内にドラッグ&ドロップすれば作成できます。ダウンロードしたadmin_console_webstart.jnlpファイルは、私の場合いくつもあるので適当に名前を変えています。

そして、続くワークフローでは「Finder項目を開く」で、「このアプリケーションで開く」で「Java Web Start」を指定します。ただ、ポップアップニューには「Java Web Start」は出てきません。ポップアップメニューで、「その他」を選択してファイル選択のダイアログボックスを表示します。そして、command+shift+Gを押して、移動先のパスを入力するシートを表示して、「/System/Library/CoreServices」に移動します。そこには、「Java Web Start」のアプリケーションがあるので選択ができます。

こうしてアプリケーション自体をサーバごとに作っておけば、ダブルクリックでAdmin Consoleを起動することができます。

[FMRP] 繰り返しフィールド、ポータル、ポータルフィルタ

しばらくさぼってしまっていましたが、FileMaker Relationship Patternsの続きです。

カテゴリ:1対多

名前:繰り返しフィールド

問題:

1エンティティに対して複数のエンティティが存在する場合に、複数のエンティティを一覧表示したい

解決策:

繰り返しフィールドを必要な数、つまり複数のエンティティに対応するフィールドの数だけ定義して、レイアウト上に配置する

フォース:

TO間の結合を定義するのではなく、フィールドのオプション設定として、繰り返す数の上限を1より大きな値に設定する事で、繰り返しフィールドを用意する

繰り返しフィールドで複数のレコードに対する保存は確保できるが、厳密な意味でのテーブル間結合ではなく、第一正規形も満たしていない点を考慮する必要がある

複数エンティティを起点としたリレーションシップは確保できず、集計処理などができない。たとえば、伝票で明細を繰り返しフィールドで作れば「伝票」という帳票は作成できるが、明細行のレコードに関して商品ごとの売り上げ集計はできなくなる。

繰り返し数の上限は、データベースの定義で決める必要がある。繰り返し数が後から足りなくなった場合に増やす事もできるが、データベースの設計変更を伴う

繰り返しフィールドはスクロールができないため、レコード数が多数になると、レイアウトの広い範囲を繰り返しフィールドが占めてしまい、使い勝手が悪いレイアウトができてしまう

関連パターン:

ポータル


カテゴリ:1対多

名前:ポータル

問題:

1エンティティに対して複数のエンティティが存在する場合に、複数のエンティティを一覧表示したい

解決策:

レイアウト上にポータルを配置して、レイアウトのTOとリレーションシップでつながっている別のTOを割り当てる。これにより、レイアウトのTOのレコードと対応関係にあるポータルのTOのレコードが、ポータルに一覧される

フォース:

典型的な1対多の展開である。リレーションで直接つながっているTOだけでなく、複数のTOを経由した先のTOでもポータルには配置できる。

ポータルの中にポータルは配置できない。ポータルの中では1対1のリレーションシップの先の単一のフィールドしか配置できない。

関連パターン:

ポータルフィルタ、繰り返しフィールド


カテゴリ:1対多

名前:ポータルフィルタ

問題:

ポータルに表示するレコードを条件に応じて制限したいが、制約をリレーションシップで定義したくない

解決策:

ポータルフィルタの設定を行う

フォース:

FileMakerのリレーションシップの制約の1つは、複数のTOが存在するTOGにおいて、すでに2つ先になっているTOと直接結合することができないことである。つまり、条件の設定をSQLのように柔軟にできないため、リレーションシップだけで必要なレコードに絞り込むことが困難な場合も出てくる。ポータルフィルタは単にレコードに式をあてはめて、表示するかどうかを判定するだけである。ただし、式に使えるフィールドはリレーションシップに影響する可能性が発生するが、1つの解決方法はグローバルフィールドを用いて条件を与え、式で判定させるということができる点がある。従って、レイアウトに表示するという状況では、リレーション以外に制約を与える方法が存在するため、すべてをリレーションで解決する必要はない。

フィルタにより一部のレコードだけが表示されるが、フィルタの式の結果がすべてtrueつまり、フィルタ前のすべてのレコードを一度は読み込むため、レイアウトを表示した最初のときに非常に時間がかかるケースも発生する。FIleMaker 12の段階では、サーバサイドでフィルタを適用しているのではなく、クライアントサイドで適用していることが原因と考えられる。

関連パターン:

ポータル

INTER-Mediatorのターゲット指定を汎用化する

INTER-Mediatorでのターゲット指定は、タグ要素のclass属性に、IM[table@field@target] といった形式で記述するものだ。これにより、tableで指定したコンテキストにあるfieldというフィールドのデータを、そのタグ要素に埋め込む。targetを省略すると、フォーム要素以外ではテキストノードとして追加し、フォーム要素ではvalueやcheckedなどの適切な属性に設定される。targetでは、Ver.3.8現在、属性名、innerHTML、nodeText、$target、#target、style.styleNameをサポートしている。

このところ、いろいろなものをINTER-Mediatorで作っていて、ある同じようなパタンが頻繁に発生していることに気付いた。それは、

あるフィールドのデータがあれば表示し、なければ表示しない

という動作である。稀に逆もあるのだが、基本は同じだ。これを実現するために、たとえば、FileMakerだと、計算フィールドを利用する。あるフィールドfieldに対して、計算フィールドdisplayField = if ( field != “”; “block” ; “none” )を定義する。そしてたとえば、こんな感じのHTMLを書く。

<div class=”IM[table@displayField@style.display]”>
データ:<span class=”IM[table@field]”></span>
</div>

SQLデータベースなら、ビューを利用するのがいいだろう。たとえば、こんな感じだろうか?

CREATE VIEW tableview AS
SELECT field, if(LENGTH(field)>0, ‘block’, ‘none’) AS displayField FROM table;

これで対処はできるとは言え、もう少し簡単にならないかと考えてしまう。こうしたよくあることを手軽に対処できるというのはフレームワークに要求されることだ。もちろん、1つの方法は、ターゲット指定の3つ目のパラメータを増やす事だ。たとえば、こんなのはどうだろう?

<div>
データ:<span class=”IM[table@field|table@field@parentVisibility]”></span>
</div>

parentVisibilityという名前の属性はないので、HTMLのルールとのコンフリクトはない。フィールドの値が “” あるいは長さが0であれば、visibilityだったら自分自身、parentVisibilityだったら1レベル上位のノードのdisplayスタイルをnoneにするというところだ。

ということで、機能を増やしました…というのはなんかこの段階に来てやることかなと疑問に考えた。もっと汎用的にすべきではないのか?

そこで考えたのが、次のような仕様である。tagetの代わりに、プログラムのステートメントのような書き方をするということ。たぶん、これがいちばん汎用的と思われる。

table@field@object.method(parameters)

だが、いきなりこれだけですというのは敷居を高くするだけじゃないのかと思われるだろう。もちろん、その解決策はある。object.method(parameters)に対するエイリアスを定義することで、従来通りの記述をサポートするようにする。つまり、…@$onclickや、…@innerHTMLという記述はサポートする。ただし、これらはエイリアスという位置づけにする。ただ、内部的には#や$の扱いが微妙だが、これはif文をがんばって書くしかないだろう。

objectは、次の書き方をサポートしようと考えている。(self) (parent) (enclosure) (repeater) つまり、カッコの中に決められたキーワードを記述する。methodとparametersは任意だ。ただ、parametersは(“a”,’b’)なんて書いたときにカッコ内をそのまま渡すのはセキュリティ上の問題が出そうな感じありありであるので、ここは制約を付けることにする。

ターゲットの3つ目に記述する処理のためのオブジェクトINTERMediatorTargetを作っておく。たとえば、そこに、次のように、setInnerHTMLメソッドがあるとしよう。ここでの関数の最初の引数は、フィールドのデータであるというルールを適用することにする。

INTERMediatorTarget {
setInnerHTML: function(d) {
this.innerHTML = d;
}
}

ターゲット指定は table@field@(self).setInnerHTML() と記述する。そして、[(self).setInnerHTML()」のエイリアスが「innerHTML」であるというわけである。

ノード展開の処理では、ターゲット指定のあるノードnodeに対して、その指定に従ったフィールドのデータfieldDataが得られている。ということは、以下のようにapplyを使えばいいということになる。これは、INTER-Mediator内部の話であって、アプリケーションを作る側は気にしなくてもいい。

INTERMediatorTarget.setInnerHTML.apply( node, [fieldData] );

このノードに展開する仕上げに相当する値をセットする部分が現状ではひどくifの応酬となっているので、まずはそれを緩和したい。また、上記のような仕組みだと、INTERMediatorTargetオブジェクトへのメソッド追加や既存メソッドの書き換えにより、フレームワークの動作を改変することも可能だし、独自のターゲット指定記述を作る事もできる。

INTERMediatorTargetに記述する関数では、前記のように第1引数にフィールド値を設定するのはいいとして、汎用性を高めるために、2、3引数はフィールド名とコンテキスト名にする。これで、コンテキストやフィールドに応じて動作を変える事もできてします。

こういう実装を考えているところである。

[IM]MediaAccessクラスと新たな拡張点(3)

こちらの文書、さらにこちらの文書の続きです。

データ生成を指定したクラスにさせ生成結果を返す

URLを使用して、別のシステムにデータを取りに行くことができるということはかなり汎用的になります。しかしながら、別システムとの連動ということになり、開発はやや大変になると同時にセキュリティ面への配慮する場面も増えることになります。そこで、INTER-Mediatorで完結させるために、定義ファイルの呼び出しにおいて、

context.php?media=class://ClassName/path/info

という呼び出しができるようになりました。この場合、ClassNameは定義ファイルと同じディレクトリなど、PHPが取得できる場所にあれば問題ありません。パス情報を付与できますが、mediaキーの値を利用することができるのです。

ClassNameで指定したクラスには、processingというメソッドを記述します。そして、ヘッダを含めた応答すべてをこのメソッドの中で完結させます。

class ClassName {
function processing($contextData, $options) { }
}

スペック上はprocessingというメソッドがあればいいのですが、引数については、とりあえず作ったアプリケーションで必要なものを並べました。$contextDataは、アクセス権の設定と同じ情報をパスに持たせることで、そのレコードのフィールドとデータがキーと値になった配列を設定します。つまり、関連付けられているレコードのデータをそのまま使えるようになっています。現状は、認証の設定がなされていないとこの変数には値は設定されません。$optionは、定義ファイルのIM_Entryの2つ目の値が設定されます。なお、メソッドの引数は今後は増えると思われます。

この仕組みを作って作ったのが『FileMaker as a Relational Database』のサイトです。このサイトでは、書籍を購入した人にPDFおよびePubでの書籍を配布していますが、それぞれパーソナライズをしています。PDFはヘッダに購入者やメールアドレスを入れ込み、ePubでは特定のページに同じような内容のテキストを埋め込んで圧縮・アーカイブします。media=class::…という記述は、そうしたドキュメント生成処理を記述できるような仕組みなのです。

MediaAccessクラスの解説は以上で終了です。