FileMakerでメディア管理 – サムネイルのタイルビュー その2 若干の技術的解説

FileMakerでメディア管理 – サムネイルのタイルビューを作った その2。ここで若干の技術的解説を付け加えておきます。

若干の技術的解説

HTMLでの画像配置について

サムネイル画像を並べたいとき、HTMLでは<img>タグで画像のURLを指定して配置します。同じことをWebビューアではできません。配置しようとしている画像がインターネット上にないからです。ではどうするか、自分のローカル環境をインターネットにします。嘘です。そんなのやってられません。

画像ファイルを貼り付けたりリンクすることを諦め、すべてHTMLの中に記述することで表示させます。つまり、表示させたい画像をテキストに変換します。

base64エンコードという言葉を聞いたことがありますね。画像をテキストに変換して、それを表示させます。テキストですからHTMLに直接書くことができます。

機能: サムネイルをクリックするとプレビュー画像が表示される

ビューアに画像を表示させるだけでは何の意味もありません。サムネイルクリックでその画像のプレビューが表示されます。

仕組みとして、サムネイルをクリックしたときに「そのレコードのIDを受け取る」ことを起こします。そしてそのIDを元にレコードを見つけて表示させます。

Webビューア内のクリック操作でIDをゲット?

ビューア内の画像クリックをすることによってIDを取得するなんてことができるんでしょうか。まったく何をどうしてよいのやら見当もつきませんでした。が、できるんです。

その答えは、FileMakerへの命令をURLとして書くことでした。そのためのスキーマが組み込まれているそうで、URLの書き方さえ知ればファイルを開いたりスクリプトを実行させることができるんです。

URLによってスクリプトを実行させられるんなら、IDゲットなんて軽くできます。それどころか、わりと何でもできますよね。Webビューアによるタイルビュー表示は、ナンチャッテでもなんでもなく、データを表示するまっとうな方法であるということを知りました。

→ この機能をフィールドに組み込んだものがこちら
その4 フィールド/ FileMakerに命令するURL 

HTMLの作り方: ひな形を元にパーツごとに生成して組み合わせる

Webビューアに表示させるにはHTMLを渡さなければなりません。それをどう作るか。テンプレートを用意してレコードのデータを当てはめながら作ります。

テンプレートを二つ用意します。一つはHTML全体、もう一つはその中に読み込むメインデータの個別パーツです。

WordPressを触っている人ならarchive.phpとその中に読み込むcontent.phpの関係をご存じかと思います。それと似た構成です。

個別パーツ用HTMLひな形に、レコードのデータを当てはめて個別パーツのHTMLを作り、それをループさせてパーツの束を作り、それを全体のHTMLに読み込みます。読み込むというか、当てはめます。

PHPでは関数を使ったりループで回したりインクルードしたりしてデータベースのデータをHTMLに落とし込みます。FileMakerで同じことができるでしょうか。できません。ですので強引に当てはめます。

検索置換の関数を使う

ひな形の中に書いた文字列を利用します。検索して置き換えるんです。

例えばひな形に

<span>ここにファイル名を置くのだ</span>

と書いたとしましょう。「ここにファイル名を置くのだ」のところに実際のファイル名データを当てはめるんです。Substituteを使って置き換えます。

Substitute(データ::HTMLひな形 ; "ここにファイル名を置くのだ" : データ::ファイル名)

と、こんな感じで、HTMLテキスト内の文字列「ここにファイル名を置くのだ」を見つけてファイル名フィールドの内容で置き換えるという、実に原始的なやり口です。

この方法を使って、テンプレートにデータを当てはめて最終的なHTMLを作成、Webビューアに表示させます。

テーブルを分けない作り

ここからは使用する実例固有の解説を少し。

タイルビュー専用のテーブルを設けません。メインの画像データベースのテーブルをそのまま使います。タイルビューのためだけに余計なテーブルを必須にするような面倒くさいことは避けたいというのが理由のひとつ。

もうひとつの理由は、メインの画像データベースのテーブルを使うことで、対象レコードをそのまま利用できるからです。

画像データベースが育っていく中で他との連携が広がりはじめると、画像データベーステーブルが起点のリレーションであることがとても重要になってきます。別テーブルでビューを司ってしまうとそちらが起点になってしまいリレーションが混乱します。

そういった理由ですが多分に個人的な好みの話でもあります。

プレビュー画面でレコードの前後移動

テーブルが共通

画像データベースと同じテーブル内でタイルビューレイアウトを作る恩恵は、「対象レコード」が共通で使えるところにあります。そのおかげで、プレビュー表示中にもレコードを前後に移動することが出来ます。

対象レコードから一意のレコードを特定する仕組み

対象レコードを温存した状態で一意のレコードを特定しプレビューすることって、意外と難しいんです。

前提として、IDは取得済みです。その手元のIDと同じIDのレコードを特定しプレビュー表示します。

簡単に特定するにはIDで検索しますが、対象レコードが一個に絞り込まれてしまいます。対象レコードから、絞り込まずにこのIDのレコードを特定したいわけです。

スクリプトステップに「レコード移動」があります。これを使うのが良さそうです。移動先としてIDを指定できるでしょうか。できません。指定できるのはレコード番号です。

レコード番号が判ればレコード移動できます。さてどうしましょう。こうします。

対象レコードをループで回して手元のIDと同じIDのレコードが来ればアタリということでそこでループを止めます。これで特定・表示できます。

はい。でもこれではちょっときついんです。別のデータベースで同じ事をやったことがあるのですけど、レコードが多くなるとめちゃ時間がかかります。速度を上げるにはどうしましょう。こうします。

レコードを直接ループさせる暴挙を取りやめ、レコードの身代わりをループさせます。身代わりとは、特定のフィールドが対象レコードと等しい状態でリストされたテキストです。

この身代わりテキストのフィールドをひとつこしらえておきます。そのフィールドをループしてレコード番号を特定し、レコードを特定し表示させます。

この身代わりフィールドとは何なのか、どうやって作るのか、その 4 フィールド – アーカイブ用のデータフィールド で続きというか詳細を説明していきます。

スクリプトを駆使せず、フィールドを駆使する

試作ファイルを作っていく中で、最初はスクリプト中心でやっていました。でもスクリプトを減らして、代わりに個別の処理をフィールドで行う方向に変更しました。

そのほうが作業の流れが把握しやすいし頭が整理できます。よく判らないままだらだらとスクリプトを書いていると、何がどうなってんのか判らなくなり混乱するのです。つまり、私がアホだからこそ、噛んで含めるように一個ずつフィールドを作っていきました。

後に理解が深まればフィールドをスクリプトに置き換えて効率良く作り直すこともできなくないですし。


若干の技術的解説でした。次回はタイルビューに必要なレイアウトについてです。

→ 次のお話 その3 レイアウト