アーキテクチャの変更…
新居雅行
は、NAME属性を使わないで、タグの種類にかかわらずTITLEタグを使うようにします。
まあ、これはたいしたことない変更ですが、プログラムはシンプルになりますし、「あ
らゆるタグの値や属性」への設定ができるようになります。
もう１つはいちばん根幹になるデータベースアクセス部分をAjaxにします。実は、「選
択入力を可能にする」という仕組みを考えていて、このままだと付け焼き刃な感じに
なるので、もっと洗練させるためです。前々から考えていたのですが、「選択肢の表
示」って究極的にはリレーションです。マスターのすべての選択肢を出すのはデカル
ト積、あるフィールドの値に依存する選択肢はまさにリレーションですね。
これを実現するために、汎用的なテーブル間の関連性を与えられるように機能を拡張
します。現状だと、デモでやっている郵便番号のリストですが、このテーブルから1対
多にあるテーブルを繰り返し表示ができません。もっとも、Filemakerだけならやりよ
うはあるのですが、汎用データベース対応するには、リレーションの先のさらにリレ
ーション…といった関係をたどってページを構成するようにする必要があります。言
い換えれば、そこまで実現すると必然的に、データに依存する選択肢の展開ができる
というわけです。一方、外部キーがどのフィールドかとうことだけでなく、結局のと
ころ、それがどのテーブルのどのフィールドと連携しているのかを記述しないといけ
ません。要はTOGを配列で定義するようなものですね。
アーキテクチャを変更しても、FileMaker Serverを使う上ではそれほど大きな違いは
ありませんが、たとえば、MySQLで、２つ先のリレーションテーブルのレコードを繰り
返し表示させるようなことも可能です。同時に、TABLEだけでなく、UL/OL、SELECTと
いったタグでの繰り返しを可能にするとともに、DIV+特定のクラスでの繰り返しも対
応しようと思っています。
そうなると、今、HTMLページにヘッダを入れてくださいとしている設定を、「コント
ローラ」としてサーバ側に展開し、クライアントは、jsファイルの読み込みみたいな
処理だけで動かせるかもしれません。そこまでやるかどうか…。また、そこまでやる
ならやるなりの「検索」処理の組み込みがあります。
いずれにしても、しばらくは考えますので、ご意見等をいただければと存じます。前
述の改造については、少しドキュメントを作って自分でも整理してからかかります。
_______________________________________________________________
新居雅行/Masayuki Nii <n...@msyk.net> <ms...@mac.com>:iChat Ready
Web Site <http://msyk.net> / INTER-Mediator [for Web App] http://msyk.net/im
OME [Email] http://mac-ome.jp / Tutoring Sevice http://msyk.net/tutoring.html
Atsushi Matsuo
先日のFM-Tokyoでは発表ありがとうございました。
バージョン0.5では非公開ディレクトリにファイルを配置できるようにもなっていたり
して、着実に機能が強化されてきていますね。
> まだ、Ver.1.0まで行っていませんが、アーキテクチャの変更を行うつもりです。1つ
> は、NAME属性を使わないで、タグの種類にかかわらずTITLEタグを使うようにします。
> まあ、これはたいしたことない変更ですが、プログラムはシンプルになりますし、「あ
> らゆるタグの値や属性」への設定ができるようになります。
title属性はツールチップやスクリーンリーダーでの読み上げに使いたい場合に都合が
悪くないか、といったあたりが少し気になりました。
> そうなると、今、HTMLページにヘッダを入れてくださいとしている設定を、「コント
> ローラ」としてサーバ側に展開し、クライアントは、jsファイルの読み込みみたいな
> 処理だけで動かせるかもしれません。そこまでやるかどうか…。また、そこまでやる
> ならやるなりの「検索」処理の組み込みがあります。
上記の「検索」処理は、レイアウトと連動したFileMakerライクな検索処理をイメージ
すればよいのでしょうか。組み込まれていると嬉しい機能ですね。
新居雅行
Atsushi Matsuo <fam...@gmail.com> さんが、2010/2/12 0:15:44に送られた
---“Re: [IM-ML-J] アーキテクチャの変更…”によりますと
> バージョン0.5では非公開ディレクトリにファイルを配置できるようにもなっていたり
> して、着実に機能が強化されてきていますね。
あ、実は、非公開ディレクトリへの配置はできません。アプリケーションの下位フォ
ルダでなくてもOKということです。これも、コントローラを分ければできるようにな
るのかな？
>
> > まだ、Ver.1.0まで行っていませんが、アーキテクチャの変更を行うつもりです。1つ
> > は、NAME属性を使わないで、タグの種類にかかわらずTITLEタグを使うようにします。
> > まあ、これはたいしたことない変更ですが、プログラムはシンプルになりますし、「あ
> > らゆるタグの値や属性」への設定ができるようになります。
>
> title属性はツールチップやスクリーンリーダーでの読み上げに使いたい場合に都合が
> 悪くないか、といったあたりが少し気になりました。
そうなんですよね。ベストな解はないと思います。当初、NAME属性でいいかと思って
いたら、DIV等INPUTではない要素ではどうしようもないです。HTMLの規則を考えて、
「あってもいい属性」でかつ、通常のレイアウトに使っていないということで「TITLE」
を使ってDIV要素への展開をしました。
ですが、結果的に要素のテキストと属性の任意のところに展開できないと、一般的な
テンプレートエンジンに劣ると言えば劣ります。そいういうことを考えた結果、「あ
らゆる属性でTITLE属性」という方針にするのがいいかと思った次第です。
ちなみに、要素に記述する必要がある情報は「テーブル名」「フィールド名」「いく
つ目か」に加えて「属性名（省略すると要素のテキスト）」ということになります。
これらを今は、セパレータとして@を使って区切って書いているのですが、「テーブル
名@フィールド名@____」でいいかなと思っています。3つ目のコンポーネントは数字な
らいくつ目、数字でなければ属性名と判断できるわけですね。となると「テーブル名@
フィールド名@3@src」ないしは「テーブル名@フィールド名@src@3」なんて指定が発生
することになりますね。「いくつ目か」はIMが勝手に付けるのですが、
>
>
> > そうなると、今、HTMLページにヘッダを入れてくださいとしている設定を、「コント
> > ローラ」としてサーバ側に展開し、クライアントは、jsファイルの読み込みみたいな
> > 処理だけで動かせるかもしれません。そこまでやるかどうか…。また、そこまでやる
> > ならやるなりの「検索」処理の組み込みがあります。
>
>
> 上記の「検索」処理は、レイアウトと連動したFileMakerライクな検索処理をイメージ
> すればよいのでしょうか。組み込まれていると嬉しい機能ですね。
検索ですが、
・レイアウトと連動したFileMakerライクなもの
・任意に設計した専用フォーム
の両方をサポートしたいと思っています。実現方法は一生懸命考えないと（笑）
Atsushi Matsuo
> あ、実は、非公開ディレクトリへの配置はできません。アプリケーションの下位フォ
> ルダでなくてもOKということです。これも、コントローラを分ければできるようにな
> るのかな？
require_once( '/Users/Shared/INTER-Mediator/INTER-Mediator.php' );
といったようにINTER-Mediator.phpを読み込むように変更してopen_basedirの設定値
を調整すれば、非公開ディレクトリへの配置もできるようになっているようです。で
も表示だけで、確かに保存処理は動きませんでした。
> そうなんですよね。ベストな解はないと思います。当初、NAME属性でいいかと思って
> いたら、DIV等INPUTではない要素ではどうしようもないです。HTMLの規則を考えて、
> 「あってもいい属性」でかつ、通常のレイアウトに使っていないということで「TITLE」
> を使ってDIV要素への展開をしました。
>
> ですが、結果的に要素のテキストと属性の任意のところに展開できないと、一般的な
> テンプレートエンジンに劣ると言えば劣ります。そいういうことを考えた結果、「あ
> らゆる属性でTITLE属性」という方針にするのがいいかと思った次第です。
できるだけ多くの要素への展開を考慮すると確かにそうですね。
単なるアイデアですが、複数の値を設定できるclass属性を利用するという手もありか
と思いました。
> 検索ですが、
>
> ・レイアウトと連動したFileMakerライクなもの
> ・任意に設計した専用フォーム
>
> の両方をサポートしたいと思っています。実現方法は一生懸命考えないと（笑）
いろいろ考える点は多そうですが、楽しみです。
新居雅行
---“Re: [IM-ML-J] Re-アーキテクチャの変更…”によりますと
> require_once( '/Users/Shared/INTER-Mediator/INTER-Mediator.php' );
> といったようにINTER-Mediator.phpを読み込むように変更してopen_basedirの設定値
> を調整すれば、非公開ディレクトリへの配置もできるようになっているようです。で
> も表示だけで、確かに保存処理は動きませんでした。
保存は、INTER-Mediator/operation_save.phpをクライアントから呼び出しているので
す。これもシングルポイントにするのがいいのかなと思っています。
> できるだけ多くの要素への展開を考慮すると確かにそうですね。
> 単なるアイデアですが、複数の値を設定できるclass属性を利用するという手もありか
> と思いました。
あーなるほど、class属性は確かにいいかもしれませんね。CSSは無視するし、重複も
OKですもんね。一方、単なるクラス指定とフィールド／テーブル名指定の区別がつか
ない場合も発生しそうですね。IM[…] みたいに記述というのもあるかもしれませんが、
ルールを重ねるとややこしくなるし、悩ましいですね。
いずれにしても、アイデアありがとうございます。検討いたします。
そういうわけで、新しいアーキテクチャの検討を開始しました。さすにがすごくやや
こしいので、一度ドキュメントをまとめてからインプリメントしようと思っています。
http://msyk.net/im/rev_arch.html
新居雅行
新居雅行 <n...@msyk.net> さんが、2010/2/14 13:44:49に送られた
---“[IM-ML-J] Re-アーキテクチャの変更…”によりますと
> あーなるほど、class属性は確かにいいかもしれませんね。CSSは無視するし、重複も
> OKですもんね。一方、単なるクラス指定とフィールド／テーブル名指定の区別がつか
> ない場合も発生しそうですね。IM[…] みたいに記述というのもあるかもしれませんが、
> ルールを重ねるとややこしくなるし、悩ましいですね。
現在、再構築中ですが、TITLEないしはCLASS属性を使うということにしようと思いま
す。両方も、一方だけでもOKとします。
TITLEの場合は、
<input title="table@field" name="email" />
などと記述します。CLASSの場合は、他のものとの区別を付けるため、
<input class="IM[table@field] mailfield" name="email" />
のようにするつもりです。もちろん、セパレータがある定義という区別の仕方もあり
ますが、確実に区別したいので、恣意的なマーキングを要求しようと思います。
それから、同じセパレータで区切って、どの属性にセットするのかを指定できるもの
とします。たとえば、input要素ならvalueに設定したいわけですから、
<input title="table@field@value" name="email" />
<input class="IM[table@field@value] mailfield" name="email" />
と書くものとします。@で区切った3つ目のコンポーネントがないものは、その要素の
値になるものとします。たとえば、
<div class="subtitle IM[table@field]"></div>
は、フィールドの値を、開きタグと閉じタグの間に展開します。
また、別の区切り文字（デバイダーと呼ぶ事にします）によって、複数の属性および
テキストデータに展開するものとします。つまり、デバイダーを縦棒の | としたら、
<option class="IM[table@id@value|table@name]" />
とすることで、
<option value="idフィールドの値">nameフィールドの値</option>
と展開するようにします。
こんな感じを考えています。