はじめに

INTER-Mediatorもバージョンを重ねてきており、以前の動作を引き継がなくなってしまった箇所が出てきています。Ver.3 (2012/12/10) 以降の大きな変更点、つまりアプリケーション側を書き換えないといけないような変更をここにまとめておきます。

Ver.12での変更

PHPのサポートバージョンは、Ver.7.4以降とします。PHPのコード上で、型の記述を行いました。そのため、アドバイザクラスなどのINTER-Mediatorにあるクラスを拡張して定義したクラスについては、引数や返り値の型の追加が必要になります。既存のアプリケーションについてはPHPコードの書き換えが必要になります。

FileMaker Serverに関しては、ベストエフォートサポートとします。こちらの文書をご覧ください。

PDOなどのデータベースクラスでは、setUpdatedRecordメソッドに3つの引数を持たせて、結果の配列の一部だけを変更する機能をサポートしていましたが、Ver.9でsetDataToUpdatedRecordメソッドを定義して、結果の一部だけを変更する機能はそちらを利用するようにしました。setUpdatedRecordメソッドは、配列を1つだけ引数に取り、結果の配列全体を設定するメソッドとしました。しかしながら、Ver.9の段階で、setUpdatedRecordメソッドを3つの引数で呼び出す場合はsetDataToUpdatedRecordメソッドをさらに呼び出して互換性を確保していましたが、その互換性はこのバージョンでなくしました。なお、データベース処理結果の配列を設定するにはsetUpdatedRecordメソッドを使ってもいいのですが、もっと手軽な方法は、doAfterReadFromDBメソッドの返り値として結果の配列を与える方法です。現状を鑑みてメソッドを整理し、余計な仕組みは取り除きました。

Ver.10での変更

params.phpで定義される変数$sendMailCompatibilityModeの初期値をfalseにしました。元はtrueだったので、何も変数定義をしないと、古いアーキテクチャーでのメール送信になっていました。デフォルトを変えたので、この変数をtrueにしない限りは新しいアーキテクチャーのメール送信機能が利用されます。以前のアプリケーションを移行する場合には気をつけてください。

package.jsonから、flatpickrの定義をなくしたので、node_modules内にはflatpickrは存在しません。CDNからダウンロードするのが良いかと思われます（samples/Sample_webpage/flatpickr_MySQL.htmlを参照）。

Ver.9での変更

LDAP認証、ネイティブ認証をサポートしなくなりました。おそらく、Ver.8で、SAML認証に対応する段階で動いていない状態だったかと思われます。機能を復活するのではなく、LDAPサーバを使いたい場合は、SAMLのIdPがLDAPを使うように設定して利用してください。ネイティブ認証については、需要がなかったということで一旦機能を落とします。なお、SAMLを始めマニュアルテストを行う場合に、その確認記録を残すようにしました。

処理中を示す「ギア」のアイコンのページがあり、画面全体をグレーで覆うので操作はできないと思われるかもしれませんが、実際にはできていました。しかしながら、連打するとおかしいとかいうクレームがあり、ギアアイコンが出ている間は操作できないようにしました。若干操作性が悪くなると思われますが、操作できるようにするには、CSSで#_im_progress {pointer-events: none;} を記述してください。

Ver.8での変更

認証の手法をかなり見直しましたが、従来のアプリケーションは、従来の設定のまま稼働するようになっています。しかしながら、そのままでは認証関連は、以前のバージョンの状態のまま稼働することになります。

まず、クレデンシャル情報をhttp-onlyのクッキーに残すようにするには、IM_Entry関数の2つ目のオプション変数等で、/authentication/storingキーに対して、credentialというキーワードを設定してください。

パスワードのハッシュをSHA-2ベースにするには、params.phpで定義している$passwordHash変数の値を"2"などにしてください。ただし、この編集だけだと、ユーザーごとにSHA-2あるいはSHA-1ベースでのハッシュを利用するため、従来のユーザーはパスワードを変更しても、SHA-1のままです。そこで、$alwaysGenSHA2 = true;とすれば、パスワードを変更する時点でSHA-2ベースのハッシュに切り替えることができます。また、$migrateSHA1to2 = true;とすれば、ログイン時など認証が通った時に、SHA-2ベースのハッシュに置き換えます。なお、従来のSHA-1のハッシュをさらにSHA-2でハッシュした、パスワード変更なくハッシュの形式だけSHA-2になるような移行措置もあります。こちらはパスワードのハッシュをまとめて変更できるような場合に有効であると考えられます。今までSHA-1ベースでの認証を行なってきていて、今後SHA-2ベースでの認証を行う場合は、authuser、issuedhashテーブルのスキーマ変更が必要になります。いくつかのフィールドの文字数を増やす必要があります。dist-docsにあるサンプルのデータベーススキーマを参照して、ご利用されているデータベースに反映させてください。

認証に関する情報は、こちらのページをご覧ください。

Ver.7での変更

inter-mediator-plugin-fileuploadは稼働しないと思われます（Ver.8では認証部分が確実に動かないことに気づき、アナウンスはVer.8の途中となりました）。このプラグインはメンテナンスしないことにしました。ファイルのアップロードは、inter-mediator-plugin-jqueryfileuploadの方を使ってください。

Ver.6での変更

対応ブラウザなどの変更

Internet Explorerはサポートしません。Edgeをご利用ください。PHPはVer.7以降です。

ファイル構成の変更

Ver.5までは、INTER-Mediatorのフォルダに原則として必要なものが入っていて手軽に始められるということを目指していましたが、Ver.6からは、composerを使ってライブラリを集める方式に変更します。そのため、ダウンロード即動くとはなっていません。詳細な文書を用意しましたので、こちらをご一読ください。

サービスサーバーの導入

サービスサーバーは、Node.jsベースで動くサーバー側の常駐プロセスです。Ver.6ではサーバー側でのバリデーションの評価のために使用していますが、今後、一般的なWebアプリケーション以外の機能をこの常駐プロセスサーバー上で構築する予定です。ただし、セットアップがやや込み入っているので、前述のセットアップに関する文書をご覧ください。

完全非同期化に伴い使用できなくなるメソッド

Ver.6.0より前は、一部の通信が同期通信でしたが、完全に非同期通信だけになったことから、同期通信関連のメソッドは非実装の状態にします。以下のメソッドがなくなります。これらのメソッドを呼び出しても該当する処理は行わず、エラーログ（ページ上部に赤いバックグランドで表示される）にメッセージ（例「INTERMediator_DBAdapter.server_access method was discontinued in Ver.6」）が追加されるだけになります。

INTERMediator_DBAdapter.server_access
INTERMediator_DBAdapter.db_query
INTERMediator_DBAdapter.db_queryWithAuth
INTERMediator_DBAdapter.db_update
INTERMediator_DBAdapter.db_updateWithAuth
INTERMediator_DBAdapter.db_delete method
INTERMediator_DBAdapter.db_deleteWithAuth
INTERMediator_DBAdapter.db_createRecord
INTERMediator_DBAdapter.db_createRecordWithAuth
INTERMediator_DBAdapter.db_copy method
INTERMediator_DBAdapter.db_copyWithAuth

廃止されるPHPのグローバル変数

Ver.6.0ではINTER-Mediator.phpで定義されているグローバル変数（$g_dbInstanceと$g_serverSideCall）が廃止される予定です。

データベース関連クラスのクラス名の変更

Ver.6のPHPのコードは、namespaceに対応しました。その時に、データベース関連のクラスが多数あったので、階層的なネームスペースに分類しました。その結果、コンテキストのextending-classに記述する名前のクラス（データベースアクセス処理の拡張クラス）について、以下のような変更が必要になります。インタフェース名として利用するものは、→の右側のように名前が変わります。インタフェースで定義されていたメソッドに変更はありません。移行時は、シンプルに、ネームスペースの絶対パスでのクラス名に置き換えれば良いでしょう。

Extending_Interface_BeforeRead → \INTERMediator\DB\Extending\BeforeRead
Extending_Interface_AfterRead → \INTERMediator\DB\Extending\AfterRead
Extending_Interface_AfterRead_WithNavigation → \INTERMediator\DB\Extending\AfterRead_WithNavigation
Extending_Interface_BeforeUpdate → \INTERMediator\DB\Extending\BeforeUpdate
Extending_Interface_AfterUpdate → \INTERMediator\DB\Extending\AfterUpdate
Extending_Interface_BeforeCreate → \INTERMediator\DB\Extending\BeforeCreate
Extending_Interface_AfterCreate → \INTERMediator\DB\Extending\AfterCreate
Extending_Interface_BeforeDelete → \INTERMediator\DB\Extending\BeforeDelete
Extending_Interface_AfterDelete → \INTERMediator\DB\Extending\AfterDelete
Extending_Interface_BeforeCopy → \INTERMediator\DB\Extending\BeforeCopy
Extending_Interface_AfterCopy → \INTERMediator\DB\Extending\AfterCopy

そのほかのデータベース関連クラスも名称変更があります。拡張クラス内で利用するようなクラスについて、ネームスペースの絶対パスを紹介しておきます。

DB_Proxy → \INTERMediator\DB\Proxy
DB_UseSharedObject → \INTERMediator\DB\UseSharedObject
DB_PDO → \INTERMediator\DB\PDO
IM_Util → \INTERMediator\IM_Util

データコンバータークラスも、クラス名は変わっています。DataConverter_AppendPrefixだったものは、\INTERMediator\Data_Converter\AppendPrefixになりました。ただし、通常はクラス名を正確に指定する必要はなく、IM_Entry関数の第２引数（オプション引数）で、formatterキーの後の連想配列で指定することになります。そこでの設定は、従来通りの名前を記述するだけです。つまり、「AppendPrefix」と指定していた箇所は、Ver.6でも「AppendPrefix」で機能します。

その他

'data-im-group'属性は、Ver.6以降利用できません。type=radioのINPUTタグについては、同一のdata-im属性のものを自動的にグループ化します。

Ver.5.12での変更

動作条件の変更

INTER-Mediator Ver.5系統ではVer.5.12でPHP 8.0に対応しましたが、PHP 5.2とPHP 5.3はサポート対象外となりました。PHP 5.4以降が必要です（推奨はPHP 7.3以降）。これに伴い、FileMaker Serverについてはバージョン13以前はサポート対象外となりました。

Ver.5.8での変更

要求されるプライベートキーの鍵長

セキュリティ上の理由から、プライベートキーの鍵長が2048bit未満のものを非推奨にしました。ネイティブ認証やLDAP認証を利用している場合には、プライベートキー（params.phpファイル内の変数 $generatedPrivateKey の値）を更新する必要があります。

Ver.5.7での変更

データベース更新処理の排他制御の変更

Ver.5.4で、IMLibUI.lockUIElementなどのメソッドを用意して、独自に排他制御をかけていましたが、ある状況でうまく機能していない場合があることがわかり、データベースへの更新処理をキューを使ってシリアライズするように変更しました。キューを使うことで、キューに登録したタスクは1つ1つが完全に終了するまで、次のタスクは実行できなくなります。データベースへの更新処理をユーザーインタフェースから呼び出すときには、必ずキューを使うので、2つの更新処理が同時に発生してしまうなどの不具合は理屈の上では発生しなくなります。また、更新前のクエリーもキューに登録されて実行されるようになります。

自分でJavaScriptでプログラムを作る場合には、キューへの登録を適切に行ってください。IMLibQueue.setTaskメソッドを使います。引数は実行するタスクを関数で指定しますが、関数には必ず引数を1つ設定してください。その引数はクロージャーが渡され、キューのタスクの終了をシステムに知らせるために、その引数のクロージャーを実行します。実行するタスクが非同期の処理を含む場合には、タスクの最後に引数のクロージャーを実行するのではなく、非同期処理の完了処理で呼び出すなどしないと、更新処理の前後が交錯して、認証の継続がうまく行かないなどのトラブルになります。以下はコードの例です。

IMLibQueue.setTask(function (completeTask) {
     INTERMediator_DBAdapter.db_query_async(
         {
             name: "execute",
             conditions: [{field: "id", operator: "=", value: id}],
             uselimit: false,
             records: 1
         },
         function (result) {
             document.getElementById("result").innerHTML = result.dbresult[0].result;
             INTERMediator.flushMessage();
             completeTask();
         },
         function () {
             INTERMediator.flushMessage();
             completeTask();
         });
});

なお、JavaScriptの以下のAPIは、内部でIMLibQueue.setTaskを呼び出しているので、キューへの設定は自動的に行われます。以下に含まれないようなINTERMediator_DBAdapter.db_query_asyncメソッドでは、上記のように、自分でキューへの登録やタスク終了の呼び出しを行う必要が発生します。

IMLibUI.valueChange
IMLibUI.copyButton
IMLibUI.deleteButton
IMLibUI.insertButton
IMLibContext.prototype.setDataAtLastRecord
IMLibContext.prototype.setDataWithKey
IMLibPageNavigation.copyRecordFromNavi
IMLibPageNavigation.deleteRecordFromNavi
IMLibPageNavigation.insertRecordFromNavi

データベースクラスに関してのリファクタリング

DB_PDO.phpファイルなどのように、データベースクラスは非常に行数が大きくなり、保守しづらい状況になっていました。そこで、DB_Supportフォルダにいくつかのファイルを作り、異能の分離をしています。一般のアプリケーションに影響はないようになっているはずですが、自分でデータベースクラスを作っているような場合には、DB_Interface.phpに記述されたインタフェースに基づいて機能を分離している点をご理解いただきプログラムに反映させてください。データベースクラスからは、publicなポインタを利用して、別途定義された「ハンドラ」を参照するといった仕組みです。なお、例えば認証に関連する部分はDB_Auth_Handler_PDO.phpファイルに記述されていますが、あるデータベースクラスが認証の機能を使わないのなら、このハンドラは定義不要で、ポインタとなるプロパティはnullのままで構いません。

一部プロパティの変更

内部的にINTERMediatorLogオブジェクトを導入したことで、プログラミングガイドでは言及されていなかった一部のプロパティが変更されています。もしもこれらのプロパティを個別のJavaScriptで利用している場合には書き換えが必要になります。

（変更前） INTERMediator.debugMode （変更後） INTERMediatorLog.debugMode
（変更前） INTERMediator.supressDebugMessageOnPage （変更後） INTERMediatorLog.suppressDebugMessageOnPage
（変更前） INTERMediator.supressErrorMessageOnPage （変更後） INTERMediatorLog.suppressErrorMessageOnPage
（変更前） INTERMediator.errorMessages （変更後） INTERMediatorLog.errorMessages
（変更前） INTERMediator.debugMessages （変更後） INTERMediatorLog.debugMessages
（変更前） INTERMediator.errorMessageByAlert （変更後） INTERMediatorLog.errorMessageByAlert
（変更前） INTERMediator.errorMessageOnAlert （変更後） INTERMediatorLog.errorMessageOnAlert

Ver.5.6での変更

テーマの新設と既存の開発物について

このバージョンより、一切のスタイル設定をしなくてもそれなりに見栄えの良いページが作成できるように、デフォルトのテーマを構築しました。また、テーマを入れ替えることで、手軽に見栄えを変更できるような機能にもなっています。しかしながら、独自にCSSを全面的に定義しているようなサイトにおいては、デフォルトのテーマの設定と当たってしまう場合もあります。その場合、「least」テーマに切り替えてください。IM_Entry関数の第2引数（オプション設定）に、"theme"がキーで、値が"least"という定義を加えまます。params.phpでは$themeName = "least"; と指定します。このテーマは、ログインパネルとページネーションの要素に適用される設定しかしていませんので、多くの場合テーマと自分のCSSが当たるということはないと思います。また、テーマのCSSは、独自のCSSファイルへのlinkタグより前に配置されるため、通常は、独自のCSSファイルでテーマの内容を上書きできるはずです。

イベント取得

キーボード関連のイベントに対する応答を登録できるグローバル変数IMLibKeyEventDispatchは、IMLibKeyDownEventDispatchとIMLibKeyUpEventDispatchに変更になりました。

ログインパネルのカスタマイズプロパティの廃止

INTERMediatorOnPage.defaultBackgroundImage、INTERMediatorOnPage.defaultBackgroundColorの2つのプロパティを廃止しました。設定しても何も起こりません。

Ver.5.5での変更

アドバイス定義クラスでメールの送信内容を修正する場合

データベースに対する処理のうち、Read/Update/Createの3つの処理が終了後にメールを送信する設定をコンテキスト定義に記述します。このとき、データベースで処理したレコードの配列を元にメールを送信するので、フィールドに送信時に使用する宛先や文面などのデータがあれば、コンテキスト定義上で使用するフィールドあるいは固定値を記述することでメールの送信ができます。しかしながら、状況によってはレコードにない情報を追加したり、あるいは変更してメール送信に利用したい場合もあります。その場合は、コンテキスト定義にextending-classキーの値を追加して、アドバイス定義クラスを実装します。そのクラスに、レコード作成直後にメールを送りたい場合の修正を組み込むため、doAfterCreateToDB($result)メソッドを実装します。このとき、書き直したフィールドや、追加したいフィールドは、データベースクラスのsetUpdatedRecordを利用して追加してください。通常、アドバイス定義クラスは、DB_UseSharedObjectsクラスを継承しているので、現在使用しているデータベース定義クラスは、dbClassプロパティで得られます。したがって、n番目のレコードのフィールドfに値vを書き込む場合は、「$this->dbClass->setUpdatedRecord（f, v, n）」というプログラムを書きます。これで、メール処理クラスに変更されたり追加されたフィールドを持つレコードが送信されます。なお、doAfterCreateToDBなどのメソッドは、基本は引数と同じレコードを返してください。メールの送信は、これらのメソッドの返り値ではなく、データベースクラスのインスタンスが管理して「結果のレコード」を利用します。返り値は、例えば、クエリー結果だと、ページ上に表示される値として利用されるものです。したがって、表示側もメール側も変更するのなら、setUpdatedRecordメソッドだけでなく、返り値の配列も変更が必要です。

なお、このように、setUpdatedRecordを使用する必要があるのは、これまでのバージョンは新規レコード作成時だけだったのですが、操作ごとに処理方法がバラついてしまっていたので、読み出しや更新処理も、同様にsetUpdatedRecordでメール処理に渡すレコード群の変更をするようにしました。

Ver.5.4での変更

サーバーサイドのPHPのAPIを整理

データベースアクセスクラスの基本メソッド

データベースアクセスクラスでは、CRUDおよびその関連処理のためのメソッドを既定しています。従来は、そのメソッドに処理しているコンテキスト名を引数として渡していましたが、それをやめました。また、メソッドの名称もCRUDの各単語に対応したものとなりました。現在処理しているコンテキスト名は、DB_SettingsクラスのメソッドgetDataSourceName()で取得できます。Ver.5.4-dev以降は、getFromDBは呼び出されず、readFromDBが呼び出されるようになるので、必要な修正をしてください。

従来の定義

interface DB_Interface extends DB_Spec_Behavior
{
    public function getFromDB($contextName);
    public function countQueryResult($contextName);
    public function getTotalCount($contextName);
    public function setToDB($contextName);
    public function newToDB($contextName, $bypassAuth);
    public function deleteFromDB($contextName);
    public function copyInDB($contextName);
}

新しい定義

interface DB_Interface extends DB_Spec_Behavior
{
    public function readFromDB();         // former getFromDB
    public function countQueryResult();
    public function getTotalCount();
    public function updateDB();           // former setToDB
    public function createInDB($bypassAuth);  // former newToDB
    public function deleteFromDB();
    public function copyInDB();
}

データベースアクセス処理の拡張クラス

コンテキストにextending-classキーで指定したクラス名にインプリメントするインタフェースを以下のように変更しました。名前をCRUDに対応するものにすると同時に、データソース名の引数は渡しません。拡張処理クラスがDB_UseSharedObjectsを継承している場合は、DB_SettingsクラスのインスタンスへdbSettingsプロパティでアクセスできます。これを利用すると、現在処理しているコンテキスト名は、DB_SettingsクラスのメソッドgetDataSourceName()で取得できます。Ver.5.4-dev以降は、従来の名称のメソッドは呼び出されず、新しいメソッドしか呼び出されませんので、必要な修正をしてください。

従来の定義

interface Extending_Interface_BeforeGet {
    public function doBeforeGetFromDB($dataSourceName);
}
interface Extending_Interface_AfterGet {
    public function doAfterGetFromDB($dataSourceName, $result);
}
interface Extending_Interface_AfterGet_WithNavigation {
    public function doAfterGetFromDB($dataSourceName, $result);
    public function countQueryResult($dataSourceName);
    public function getTotalCount($dataSourceName);
}
interface Extending_Interface_BeforeSet {
    public function doBeforeSetToDB($dataSourceName);
}
interface Extending_Interface_AfterSet {
    public function doAfterSetToDB($dataSourceName, $result);
}
interface Extending_Interface_BeforeDelete {
    public function doBeforeDeleteFromDB();
}
interface Extending_Interface_AfterDelete {
    public function doAfterDeleteFromDB($result);
}
interface Extending_Interface_BeforeNew {
    public function doBeforeNewToDB($dataSourceName);
}
interface Extending_Interface_AfterNew{
    public function doAfterNewToDB($dataSourceName, $result);
}

新しい定義

interface Extending_Interface_BeforeRead {
    public function doBeforeReadFromDB();
}
interface Extending_Interface_AfterRead {
    public function doAfterReadFromDB($result);
}
interface Extending_Interface_AfterRead_WithNavigation {
    public function doAfterReadFromDB( $result);
    public function countQueryResult();
    public function getTotalCount();
}
interface Extending_Interface_BeforeUpdate {
    public function doBeforeUpdateDB();
}
interface Extending_Interface_AfterUpdate {
    public function doAfterUpdateToDB($result);
}
interface Extending_Interface_BeforeCreate {
    public function doBeforeCreateToDB();
}
interface Extending_Interface_AfterCreate {
    public function doAfterCreateToDB($result);
}
interface Extending_Interface_BeforeDelete {
    public function doBeforeDeleteFromDB();
}
interface Extending_Interface_AfterDelete {
    public function doAfterDeleteFromDB($result);
}
interface Extending_Interface_BeforeCopy {
    public function doBeforeCopyInDB();
}
interface Extending_Interface_AfterCopy {
    public function doAfterCopyInDB($result);
}

DB_Settingsクラスの整理統合

以下のメソッドはVer.5.4-devでは定義されていません。代替メソッドを使ってください。

function getTargetName()
function getTargetDataSource()
function setTargetDataSource($targetDataSource)
function getIndexOfDataSource($dataSourceName)
function setTargetFields($fields)

getTargetName/getTargetDataSource/setTargetDataSourceメソッドは、ほぼ同一の動きをするgetDataSourceName/setDataSourceNameメソッドに置き換えました。setTargetFieldsとgetIndexOfDataSourceメソッドは使われていないので、削除しました。

Ver.5.3での変更

CSRF攻撃対策の追加

params.phpファイルで$webServerNameという変数を設定することでCSRF攻撃対策を実施することができるようになりました。Webサーバーのドメイン名もしくはFQDN（完全修飾ドメイン名）を配列で設定するようにしてください。
設定例1：array('inter-mediator.com');
設定例2：array('www.inter-mediator.com', 'inter-mediator.org');

Ver.5.2での変更

データベースクラスでのメソッド定義の変更

Auth_Interface_DBインタフェースで定義しているauthSuportCreateUserメソッドの引数が、LDAP対応に伴い2つから4つに増えました。データベースクラス（DB_PDO.phpなど）については、機能を組み込んでいなくても、メソッドの引数をインタフェースでの定義に揃えなければなりません。定義内容は、DB_Interfaces.phpファイルを参照してください。

Ver.4.7での変更

Internet Explorer Ver.8対応に関して

これまでは、Internet Explorerの最低サポートバージョンをVer.8としてきましたが、Ver.4.7現在、いくつかの機能が動かない状態になっています。これらについては、今後サポートする予定はありません。しかしながら、主要な機能はVer.4.7でも動いているので、IE8のサポートバージョンとして、最後のものがVer.4.7とします。Ver.4.7でIE8で動作に問題があるものとして、以下のものがわかっています。

フィールドの文字列中に改行がある場合、TEXTAREAに正しく表示されない。これは、改行をBRタグに変更してinnerHTMLに設定するという手段が、IE8ではエラーになってしまうためです。
Pusherをベースにしたクライアント間同期の仕組みのうち、レコード削除後の処理でエラーが出る。フィールドの更新や新規レコードは稼働します。
ローカルコンテキストを利用して、検索パラメータを指定する機能のうち、1ページの件数の制限と、並べ替えに使用するフィールドの指定が正しく動作しません。検索条件と、「検索」ボタンは動作します。

なお、Ver.5以降は、IE8のためのコードを削除する可能性もあり、動かない機能がより増える可能性もあります。また、Ver.5以降は、Internet Explorerでの確認は、主として最新バージョンでのみ行うことにします。Firefox、Chrome、Safariと同様な扱いにします。なお、特定のバージョンでの不具合について、対応を希望する場合には、Facebookのグループ等でリクエストを出してください。

Ver.4.6での変更

setExeucteメソッド

グローバル変数のIMLibChangeEventDispatch、IMLibKeyEventDispatch、IMLibMouseEventDispatchの初期化は、constructメソッドを呼び出す後になりました。これらのオブジェクトで利用できていた、setExeucteなどのメソッドは、constructを呼び出した後に設定してください。具体的には、INTERMediatorOnPage.doAfterConstruct = function() { } という関数の定義と代入を行い、関数内でIMLibChangeEventDispatch、IMLibKeyEventDispatch、IMLibMouseEventDispatchを利用してください。

INTERMediator.additionalCondition, additionalSortKeyプロパティ

コンテキストを利用して読み出しを行うとき、JavaScriptで検索条件や並べ替え条件を付加できるプロパティadditionalConditionとadditionalSortKeyがあります。これらは、従来までは単純にオブジェクトを記録していただけですが、Ver.4.4あたりでローカルコンテキストに記録して、ページを改めて呼び出した時にローカルコンテキストを復活させることで元に戻すという仕様を組み込みました。しかしながら、その動作を見直している時にバグが見つかりましたが、結果的に、additionalConditionとadditionalSortKeyの参照は変更ありませんが、追加や書き換えには以下のような変更が必要になります。これらの2つのプロパティにセッタとゲッタを設定しているため、セッタを稼働させるために、プロパティそのものへの代入が必要になります。あるいは、新しいAPIのaddConditionやaddSortKeyメソッドを利用してください。追加した条件を消去するclearConditions、clearSortKeysメソッドも利用できます。

INTERMediator.additionalCondition["acontext"] = [];
INTERMediator.additionalCondition["acontext"].push({field: "afield", operator: "=", value: "1001"});
INTERMediator.additionalCondition["acontext"].push({field: "live", operator: "=", value: "1"});

    ↓

（修正方法A）
INTERMediator.addCondition("acontext", {field: "afield", operator: "=", value: "1001"});
INTERMediator.addCondition("acontext", {field: "live", operator: "=", value: "1"});

（修正方法B）
var conditions = INTERMediator.additionalCondition;
conditions["acontext"] = [];
conditions["acontext"].push({field: "afield", operator: "=", value: "1001"});
conditions["acontext"].push({field: "live", operator: "=", value: "1"});
INTERMediator.additionalCondition = conditions

検索条件が1つだけの場合も、同様に、次のように書き換えが必要になります。

INTERMediator.additionalCondition["acontext"] = {field: "afield", operator: "=", value: "1001"};

    ↓

（修正方法A）
INTERMediator.addCondition("acontext", {field: "afield", operator: "=", value: "1001"});

（修正方法B）
var conditions = INTERMediator.additionalCondition;
conditions["acontext"].push({field: "afield", operator: "=", value: "1001"});
INTERMediator.additionalCondition = conditions

Ver.4.5での変更

valueChangeメソッド

INTERMediator.valueChange(idValue)はIMLibUI.valueChange(idValue)に変更されました。もしもJavaScriptのプログラム内でvalueChangeメソッドを使用している場合には書き換えが必要です。

Ver.4.1 (2014/2/7) での変更

ターゲット指定をclass属性に独自の記述方法で書いていましたが、Ver.4.1より、HTML5のdata属性での記述に移行しました。なお、従来の記述も基本的にはそのまま利用できるはずですが、大した手間にならないので、書き直すのがいいかと思います。

以前の表記法	Ver.4.1以降の表記法	利用場所
class="IM[...]"	data-im="..."	ページファイルのターゲット指定
class="IM_WIDGET[...]"	data-im-widget="..."	JavaScriptコンポーネントの指定
class="_im_enclosure"	data-im-control="enclosure"	エンクロージャにしたいDIV, SPANタグ
class="_im_repeater"	data-im-control="repeater"	リピータにしたいDIV, SPANタグ
class="_im_ignore_enc_rep"	data-im-control="ignore_enc_rep"	リピータあるいはエンクロージャでなくする
class="_im_for_noresult_"	data-im-control="noresult"	検索結果が0レコードの時に表示されるリピータ
class="_im_post"	data-im-control="post"	ポストオンリーモードのエンクロージャおよび書き込みボタン
name="IM[...]"	data-im-group="...."	ポストオンリーモードでのラジオボタンのグループ指定

以下は書き換え例です。

<input class="IM[mytable@anyfield]" />
    ↓
<input data-im="mytable@anyfield" />

IM[]に複数のターゲット指定を書いていた場合、|で区切っていましたが、空白で区切れるようになりました。

<option class="IM[mytable@myvalue@value|mytable@myname]" />
    ↓
<option data-im="mytable@myvalue@value mytable@myname" />

Ver.4.0 (2013/12/4) での変更

INTER-Mediatorの配布ファイルのファイル構成が変わりました。ルート直下にフレームワークがあり、サンプルファイルはSamplesの下に配備しました。同時に、dist-docs/buildup.shを利用して、運用向けのフレームワークを用意する機能を加えています。こちらをごらんください。

Ver.3.8 (2013/8/22) での変更

params.phpファイルにおいて記述できていた$scriptPathPrefix、$scriptPathSufixを利用して、クライアントから呼び出すURLをコントロールできていましたが、$callURLという変数で完全にURLで指定できるようにしています。$scriptPathPrefix、$scriptPathSufixも使用できます。