Maple 3.2.0を使っていて分かった事がある。それは非グローバルフィルター(グローバルフィルターでないフィルターの事で、色々資料を読んでも何と呼んでいるのか分からなかったので勝手に命名した)とはローカルフィルターではない事に注意すること。
これに気付くまでは非グローバルフィルターはローカルフィルターだと思い込んでいた。
非グローバルフィルターとは、該当するディレクトリー内にしか影響を与えないようにも取れるが、Maple 3.2.0の場合(それ以前のバージョンでも同じかもしれないが調べていないのでそれ以前のバージョンについては不明)上位の非グローバルフィルターの影響を受ける事に注意する必要がある。
(つまり非グローバルフィルターはローカルフィルターではない。非グローバルフィルターも半グローバルフィルター的な要素がある。)
非グローバルフィルターの場合、非グローバルフィルターを記述したmaple.iniを置いたディレクトリに適用されるのが基本であるが、上位ディレクトリーに、同一の非グローバルフィルターを記述したmaple.iniが存在する場合、上位ディレクトリーに記述した非グローバルフィルターのパラメータは下位ディレクトリーの非グローバルフィルターに引き継がれる。
上位ディレクトリーのmaple.iniに非グローバルフィルターを記述していても、下位ディレクトリーに前記非グローバルフィルターを記述していない場合は、フィルター自体が適用されないのでパラメータは引き継がれない。
例えば、「a」ディレクトリー下に「b」ディレクトリーがあるディレクトリー構成で、各々のディレクトリー内にあるmaple.iniの内容が以下のような場合について「b」ディレクトリーに適用されるフィルターのパラメータを考えて見る。
・「a」ディレクトリーのmaple.ini
[Validate]
user_id.required = "1,ユーザIDを入力してください。"
password.required = "1,パスワードを入力してください。"
・「b」ディレクトリーのmaple.ini
[Validate]
この場合「b」ディレクトリーには、Validateフィルターが適用される。しかも「a」ディレクトリーのmaple.iniに記述したパラメータ「user_id.required = "1,ユーザIDを入力してください。"」および、「password.required = "1,パスワードを入力してください。"」も引き継がれる。(「b」ディレクトリー内のmaple.iniにはパラメータを記述していないにもかかわらず。)
逆に「a」ディレクトリーのmaple.iniに記述したパラメータを引き継ぎたくない場合には、「b」ディレクトリーのmaple.iniを以下のように記述する。
・「b」ディレクトリーのmaple.ini
[Validate]
user_id.required =
password.required =
これにより、「a」ディレクトリーのパラメータが「b」ディレクトリーのmaple.iniを読み込んだ時点で空文字列でオーバライトされて、「b」ディレクトリーでは無効となる。
さらに補足すると、「b」ディレクトリーのmaple.iniにValidateフィルターを記述しない場合(上記例の場合においては「b」ディレクトリーのmaple.iniの内容を空にした場合)は、「b」ディレクトリーにはValidateフィルターが適用されないので、「a」ディレクトリーのmaple.iniに記述したValidateフィルターのパラメータは無視される。
仮に「a」ディレクトリーのmaple.iniの内容を以下のようにし、Validateフィルターをグローバルフィルターとして記述すると、「b」ディレクトリーのmaple.iniにValidateフィルターを記述しない場合でも「b」ディレクトリーにValidateフィルターが適用され、パラメータも引き継がれる事になる。
・「a」ディレクトリーのmaple.ini
[GlobalFilter]
Validate =
[Validate]
user_id.required = "1,ユーザIDを入力してください。"
password.required = "1,パスワードを入力してください。"
つまりグローバルフィルターとしてフィルターを記述しなくても、グローバルフィルター的な挙動をするのでmaple.iniを記述する場合には、この事を考慮すること。
なお、フィルターの設定方法については、ここの「設定ファイルの仕様」−「maple.ini」が参考になる。
これに気付くまでは非グローバルフィルターはローカルフィルターだと思い込んでいた。
非グローバルフィルターとは、該当するディレクトリー内にしか影響を与えないようにも取れるが、Maple 3.2.0の場合(それ以前のバージョンでも同じかもしれないが調べていないのでそれ以前のバージョンについては不明)上位の非グローバルフィルターの影響を受ける事に注意する必要がある。
(つまり非グローバルフィルターはローカルフィルターではない。非グローバルフィルターも半グローバルフィルター的な要素がある。)
非グローバルフィルターの場合、非グローバルフィルターを記述したmaple.iniを置いたディレクトリに適用されるのが基本であるが、上位ディレクトリーに、同一の非グローバルフィルターを記述したmaple.iniが存在する場合、上位ディレクトリーに記述した非グローバルフィルターのパラメータは下位ディレクトリーの非グローバルフィルターに引き継がれる。
上位ディレクトリーのmaple.iniに非グローバルフィルターを記述していても、下位ディレクトリーに前記非グローバルフィルターを記述していない場合は、フィルター自体が適用されないのでパラメータは引き継がれない。
例えば、「a」ディレクトリー下に「b」ディレクトリーがあるディレクトリー構成で、各々のディレクトリー内にあるmaple.iniの内容が以下のような場合について「b」ディレクトリーに適用されるフィルターのパラメータを考えて見る。
・「a」ディレクトリーのmaple.ini
[Validate]
user_id.required = "1,ユーザIDを入力してください。"
password.required = "1,パスワードを入力してください。"
・「b」ディレクトリーのmaple.ini
[Validate]
この場合「b」ディレクトリーには、Validateフィルターが適用される。しかも「a」ディレクトリーのmaple.iniに記述したパラメータ「user_id.required = "1,ユーザIDを入力してください。"」および、「password.required = "1,パスワードを入力してください。"」も引き継がれる。(「b」ディレクトリー内のmaple.iniにはパラメータを記述していないにもかかわらず。)
逆に「a」ディレクトリーのmaple.iniに記述したパラメータを引き継ぎたくない場合には、「b」ディレクトリーのmaple.iniを以下のように記述する。
・「b」ディレクトリーのmaple.ini
[Validate]
user_id.required =
password.required =
これにより、「a」ディレクトリーのパラメータが「b」ディレクトリーのmaple.iniを読み込んだ時点で空文字列でオーバライトされて、「b」ディレクトリーでは無効となる。
さらに補足すると、「b」ディレクトリーのmaple.iniにValidateフィルターを記述しない場合(上記例の場合においては「b」ディレクトリーのmaple.iniの内容を空にした場合)は、「b」ディレクトリーにはValidateフィルターが適用されないので、「a」ディレクトリーのmaple.iniに記述したValidateフィルターのパラメータは無視される。
仮に「a」ディレクトリーのmaple.iniの内容を以下のようにし、Validateフィルターをグローバルフィルターとして記述すると、「b」ディレクトリーのmaple.iniにValidateフィルターを記述しない場合でも「b」ディレクトリーにValidateフィルターが適用され、パラメータも引き継がれる事になる。
・「a」ディレクトリーのmaple.ini
[GlobalFilter]
Validate =
[Validate]
user_id.required = "1,ユーザIDを入力してください。"
password.required = "1,パスワードを入力してください。"
つまりグローバルフィルターとしてフィルターを記述しなくても、グローバルフィルター的な挙動をするのでmaple.iniを記述する場合には、この事を考慮すること。
なお、フィルターの設定方法については、ここの「設定ファイルの仕様」−「maple.ini」が参考になる。
Maple 3.2.0 からは config ディレクトリーが maple ディレクトリーの下に移動したようである。
Maple 3.1.1 のサンプルを動作させた際には、webapp ディレクトリーの下にあったので、webapp ディクレクトリー内の config を使用したが、今回はmaple ディレクトリーの下の config を使用して動作するようにしてみた。
もっと修正箇所を減らす事もできそうだが、以下のように修正して動作させて見た。なお、以下の修正を行ったmapleで3.1.1のサンプルを動かしてはいないので、サンプルを動かすためには他を修正しないといけないかもしれない。(特にコンポーネントを使うサンプル)
今の自分にはサンプルを動かす必要性がなくなってしまったので、サンプルが動くかどうかの確認はしていない。
(1)maple\config\common.php(29L)
変更前:
define('BASE_INI', '/config/base.ini');
変更後:
define('BASE_INI', '/webapp/base.ini');
(2)maple\config\webapp\base.ini(複数)
変更前(例):
path = maple/core/ConfigUtils.class.php
変更後(例):
path = core/ConfigUtils.class.php
---> 他のpathについても「maple/」部分を削除した。
(3)maple\config\webapp\maple.inc.php(31-32L)
変更前:
define('WEBAPP_DIR', dirname(dirname(__FILE__)));
define('MAPLE_DIR', 'maple');
変更後:
define('WEBAPP_DIR', BASE_DIR . '/webapp');
define('MAPLE_DIR', BASE_DIR . '/maple');
define('CONFIG_DIR', dirname(dirname(__FILE__)));
define('SMARTY_DIR', MAPLE_DIR . '/smarty/');
(4)maple\config\webapp\maple.inc.php(74L)
変更前:
ini_set('include_path', COMPONENT_DIR . PATH_SEPARATOR . ini_get('include_path'));
変更後:
ini_set('include_path', MAPLE_DIR . PATH_SEPARATOR . ini_get('include_path'));
(5)maple\core\Controller.class.php(117L)
変更前:
if (!@file_exists(WEBAPP_DIR . BASE_INI)) {
変更後:
if (!@file_exists(CONFIG_DIR . BASE_INI)) {
(6)maple\core\Controller.class.php(123L)
変更前:
$config = parse_ini_file(WEBAPP_DIR . BASE_INI, TRUE);
変更後:
$config = parse_ini_file(CONFIG_DIR . BASE_INI, TRUE);
(7)maple\core\Controller.class.php(23L)
変更前:
require_once "Smarty.class.php";
変更後:
require_once SMARTY_DIR . 'Smarty.class.php';
Maple 3.1.1 のサンプルを動作させた際には、webapp ディレクトリーの下にあったので、webapp ディクレクトリー内の config を使用したが、今回はmaple ディレクトリーの下の config を使用して動作するようにしてみた。
もっと修正箇所を減らす事もできそうだが、以下のように修正して動作させて見た。なお、以下の修正を行ったmapleで3.1.1のサンプルを動かしてはいないので、サンプルを動かすためには他を修正しないといけないかもしれない。(特にコンポーネントを使うサンプル)
今の自分にはサンプルを動かす必要性がなくなってしまったので、サンプルが動くかどうかの確認はしていない。
(1)maple\config\common.php(29L)
変更前:
define('BASE_INI', '/config/base.ini');
変更後:
define('BASE_INI', '/webapp/base.ini');
(2)maple\config\webapp\base.ini(複数)
変更前(例):
path = maple/core/ConfigUtils.class.php
変更後(例):
path = core/ConfigUtils.class.php
---> 他のpathについても「maple/」部分を削除した。
(3)maple\config\webapp\maple.inc.php(31-32L)
変更前:
define('WEBAPP_DIR', dirname(dirname(__FILE__)));
define('MAPLE_DIR', 'maple');
変更後:
define('WEBAPP_DIR', BASE_DIR . '/webapp');
define('MAPLE_DIR', BASE_DIR . '/maple');
define('CONFIG_DIR', dirname(dirname(__FILE__)));
define('SMARTY_DIR', MAPLE_DIR . '/smarty/');
(4)maple\config\webapp\maple.inc.php(74L)
変更前:
ini_set('include_path', COMPONENT_DIR . PATH_SEPARATOR . ini_get('include_path'));
変更後:
ini_set('include_path', MAPLE_DIR . PATH_SEPARATOR . ini_get('include_path'));
(5)maple\core\Controller.class.php(117L)
変更前:
if (!@file_exists(WEBAPP_DIR . BASE_INI)) {
変更後:
if (!@file_exists(CONFIG_DIR . BASE_INI)) {
(6)maple\core\Controller.class.php(123L)
変更前:
$config = parse_ini_file(WEBAPP_DIR . BASE_INI, TRUE);
変更後:
$config = parse_ini_file(CONFIG_DIR . BASE_INI, TRUE);
(7)maple\core\Controller.class.php(23L)
変更前:
require_once "Smarty.class.php";
変更後:
require_once SMARTY_DIR . 'Smarty.class.php';
ここを参考に、Viewの動的変更に対応した。
極力標準モジュールには手を入れたくなかったのであるが、どうしても Filter_View を変更せざる得ない状況なので Filter_View の内容をこの内容に基づいて一部修正した。
また認証フィルターを使用する場合には、View を表示する部分があるので、こちらも Filter_View と同様な修正を行った。
あと、ここには書かれていないが、携帯サイト対応をしようとすると、文字コードをどうするか問題となる。
Maple 3.2.0 のデフォルトの文字コードは EUC-JP なので、ユーザエージェントによりアクセスしてきたデバイスが携帯ならば、どこかで SJIS に変換してやる必要がある。
Smarty4Maple.class.php クラスで出力する際の文字コードを変換するためのアウトプットフィルターを登録しているので、この処理を派生クラスでオーバライドして、デバイスに応じて適切な文字コードを設定するようにした。
具体的には、以下のように対応した。
(1)デバイス判定
PEARライブラリの Net_UserAgent_Mobile クラスを使用してデバイスを判定する Device.class.php と Filter_Device.class.php を作成した。Filter_Device.class.php で Device.class.php で定義したクラスのオブジュクトを DIContainer に登録する。後でこの情報を元に、Viewの文字コードを設定する。
(2)文字コードの設定
Smarty4Maple.class.php で定義している Smarty4Maple クラスを基底クラスとする派生クラス Smarty4Maple2 を Smarty4Maple2.class.php で定義する。
Smarty4Maple2 では Smarty4Maple::_registerFilters() をオーバライドし、ここで前記(1)項で DIContainer に登録したオブジェクトの内容によりアウトプットフィルターを設定する。
(3)Fiter_Viewの修正
この内容と併せて次の点についても修正した。Smartyのレンダラーとして、Smarty4Maple2 にインスタンスを取得するように変更した。
これにより、動的にViewおよび文字コードを変更する事ができるようになった。
なお、アウトプットフィルターで、文字コードを変換する事により、携帯対応のViewについても EUC コードで記述する事ができる。(SJISコードで記述する必要はない。)
極力標準モジュールには手を入れたくなかったのであるが、どうしても Filter_View を変更せざる得ない状況なので Filter_View の内容をこの内容に基づいて一部修正した。
また認証フィルターを使用する場合には、View を表示する部分があるので、こちらも Filter_View と同様な修正を行った。
あと、ここには書かれていないが、携帯サイト対応をしようとすると、文字コードをどうするか問題となる。
Maple 3.2.0 のデフォルトの文字コードは EUC-JP なので、ユーザエージェントによりアクセスしてきたデバイスが携帯ならば、どこかで SJIS に変換してやる必要がある。
Smarty4Maple.class.php クラスで出力する際の文字コードを変換するためのアウトプットフィルターを登録しているので、この処理を派生クラスでオーバライドして、デバイスに応じて適切な文字コードを設定するようにした。
具体的には、以下のように対応した。
(1)デバイス判定
PEARライブラリの Net_UserAgent_Mobile クラスを使用してデバイスを判定する Device.class.php と Filter_Device.class.php を作成した。Filter_Device.class.php で Device.class.php で定義したクラスのオブジュクトを DIContainer に登録する。後でこの情報を元に、Viewの文字コードを設定する。
(2)文字コードの設定
Smarty4Maple.class.php で定義している Smarty4Maple クラスを基底クラスとする派生クラス Smarty4Maple2 を Smarty4Maple2.class.php で定義する。
Smarty4Maple2 では Smarty4Maple::_registerFilters() をオーバライドし、ここで前記(1)項で DIContainer に登録したオブジェクトの内容によりアウトプットフィルターを設定する。
(3)Fiter_Viewの修正
この内容と併せて次の点についても修正した。Smartyのレンダラーとして、Smarty4Maple2 にインスタンスを取得するように変更した。
これにより、動的にViewおよび文字コードを変更する事ができるようになった。
なお、アウトプットフィルターで、文字コードを変換する事により、携帯対応のViewについても EUC コードで記述する事ができる。(SJISコードで記述する必要はない。)
以前の記事でちょっとだけ触れた認証フィルターについて補足する。
上記ページにおける「ダウンロード」リンクがリンク切れになっている。ダウンロードしたい場合にはここのAuth.zipをダウンロードすれば良い。
ホームページを作成する際に認証処理を書くのは面倒であるのだが、本モジュールを使用する事によりソースコードに記述する必要がなくなるので、ソースコードをすっきり書くことができるようになる。
本モジュールを使用するにあたっては、以下の点を修正して使っている。(ViewとしてSmartyを使う事を前提にしている。)
(1)Smartyにアサインするエラー変数
元の Filter_Auth.class.php では、$message という変数にアサインしており、Filter_View.class.php と整合性が取れていない(Filter_View.class.phpではerrorListオブジェクトをSmartyに登録)ので、エラーメッセージを errorListオブジェクトとして登録するように変更した。
変更方法は、Filter_View.class.php を参考にした。
(2)AuthLevelのレベルの優先順位の変更
元の Filter_AuthLevel.class.php では、レベルの数値が大きいほど、権限が大きくなるようになっていた。これを数値が小さいほど権限が大きくなるように変更した。
(3)Sessionに登録する情報
元の Auth.class.php では、ログインするとセッションにユーザIDを登録していたが、パスワードなど秘密情報以外をセッションに登録するように変更した。
これにともない、Filter_AuthLevel.class.php で権限のレベルを確認する際に、DBにアクセスしていたものをセッションに登録したレベルを取得するように変更した。
上記ページにおける「ダウンロード」リンクがリンク切れになっている。ダウンロードしたい場合にはここのAuth.zipをダウンロードすれば良い。
ホームページを作成する際に認証処理を書くのは面倒であるのだが、本モジュールを使用する事によりソースコードに記述する必要がなくなるので、ソースコードをすっきり書くことができるようになる。
本モジュールを使用するにあたっては、以下の点を修正して使っている。(ViewとしてSmartyを使う事を前提にしている。)
(1)Smartyにアサインするエラー変数
元の Filter_Auth.class.php では、$message という変数にアサインしており、Filter_View.class.php と整合性が取れていない(Filter_View.class.phpではerrorListオブジェクトをSmartyに登録)ので、エラーメッセージを errorListオブジェクトとして登録するように変更した。
変更方法は、Filter_View.class.php を参考にした。
(2)AuthLevelのレベルの優先順位の変更
元の Filter_AuthLevel.class.php では、レベルの数値が大きいほど、権限が大きくなるようになっていた。これを数値が小さいほど権限が大きくなるように変更した。
(3)Sessionに登録する情報
元の Auth.class.php では、ログインするとセッションにユーザIDを登録していたが、パスワードなど秘密情報以外をセッションに登録するように変更した。
これにともない、Filter_AuthLevel.class.php で権限のレベルを確認する際に、DBにアクセスしていたものをセッションに登録したレベルを取得するように変更した。
Maple 3.2.0 でセッション関係の処理をしているのが以下の2つのモジュールである。
・maple\core\Session.class.php
・maple\filter\Filter_Session.class.php
Filter_Session.class.php は、Mapleのフィルターであり、Session.class.php を生成し、DIContainerに登録しているだけなので、実際の処理は Session.class.php で行っているようだ。
Session.class.php を見てみると、 Session::start() で session_start() をコールしているが、リジェネレートをしている様子はない。
そこでセッションをリジェネレートするコードを、Session::start() に追加すれば良いのではあるが、Session.class.php は標準モジュールなので(Filter_Session.class.phpも含めて)修正するのは得策ではない。バージョンアップする際の手間を考えると。
そこで、Session.class.php で定義されている Session クラスを基底クラスとする派生クラス Session2 を Session2.class.php に定義して、Session::start() を Session2側でオーバライドする事とした。
また、Filter_Session.class.php で定義されている Filter_Session も同様に修正したくないので、Filter_Session を基底クラスとする派生クラス Filter_Session2 を Filter_Session2.class.php に定義して、Filter_Session2 で、DIContainer に sessionオブジェクト として、Session2 オブジェクトを登録する事とした。
あとは、セッションを使いたい場所の maple.ini に[Sesion]と記述する代わりに[Session2]と記述すればセッション開始時にセッションをリジェネレートできるようになる。
・maple\core\Session.class.php
・maple\filter\Filter_Session.class.php
Filter_Session.class.php は、Mapleのフィルターであり、Session.class.php を生成し、DIContainerに登録しているだけなので、実際の処理は Session.class.php で行っているようだ。
Session.class.php を見てみると、 Session::start() で session_start() をコールしているが、リジェネレートをしている様子はない。
そこでセッションをリジェネレートするコードを、Session::start() に追加すれば良いのではあるが、Session.class.php は標準モジュールなので(Filter_Session.class.phpも含めて)修正するのは得策ではない。バージョンアップする際の手間を考えると。
そこで、Session.class.php で定義されている Session クラスを基底クラスとする派生クラス Session2 を Session2.class.php に定義して、Session::start() を Session2側でオーバライドする事とした。
また、Filter_Session.class.php で定義されている Filter_Session も同様に修正したくないので、Filter_Session を基底クラスとする派生クラス Filter_Session2 を Filter_Session2.class.php に定義して、Filter_Session2 で、DIContainer に sessionオブジェクト として、Session2 オブジェクトを登録する事とした。
あとは、セッションを使いたい場所の maple.ini に[Sesion]と記述する代わりに[Session2]と記述すればセッション開始時にセッションをリジェネレートできるようになる。
認証用Filterという便利なモジュールを見つけ、色々遊んでいたのでちょっと遅くなってしまったが、前回動作しなかったexample2とexample6を動作させてみた。
いつものように結論から言うと、以下を変更し正しく動作するようになった。
・ファイル名: maple\core\DIContainer.class.php
・該当行1: 309行目(近辺)
・該当コード1(変更前): $filename = "${classPath}/${basename}.class.php";
・該当コード1(変更後): $filename = COMPONENT_DIR . "/${classPath}/${basename}.class.php";
・該当行2: 311行目(近辺)
・該当コード2(変更前): $filename = "${basename}.class.php";
・該当コード2(変更後): $filename = COMPONENT_DIR . "/${basename}.class.php";
・該当行3: 319行目(近辺)
・該当コード3(変更前): $filename = "${classPath}/${className}.class.php";
・該当コード3(変更後): $filename = COMPONENT_DIR . "/${classPath}/${className}.class.php";
読み込むコンポーネントの基点となるディレクトリ(COMPONENT_DIR)が抜けている(よう)なので、上記のように追加した。
しかし標準のコアモジュールを修正しないとサンプルコードが動かないというのも変なので、このやり方は正しくないのかもしれない。(気味が悪い。)
なお Maple 3.1.1 の DIContainer.class.php には、COMPONENT_DIR が記述されているので Maple 3.2.0 では意図的に削除したものだと思われる。
このため Maple 3.2.0 では dicon.ini 側(など)で基準となるディレクトリ(COMPONENT_DIR)を記述できるようになっているのかもしれないが、今は深く追求しない事とする。
いつものように結論から言うと、以下を変更し正しく動作するようになった。
・ファイル名: maple\core\DIContainer.class.php
・該当行1: 309行目(近辺)
・該当コード1(変更前): $filename = "${classPath}/${basename}.class.php";
・該当コード1(変更後): $filename = COMPONENT_DIR . "/${classPath}/${basename}.class.php";
・該当行2: 311行目(近辺)
・該当コード2(変更前): $filename = "${basename}.class.php";
・該当コード2(変更後): $filename = COMPONENT_DIR . "/${basename}.class.php";
・該当行3: 319行目(近辺)
・該当コード3(変更前): $filename = "${classPath}/${className}.class.php";
・該当コード3(変更後): $filename = COMPONENT_DIR . "/${classPath}/${className}.class.php";
読み込むコンポーネントの基点となるディレクトリ(COMPONENT_DIR)が抜けている(よう)なので、上記のように追加した。
しかし標準のコアモジュールを修正しないとサンプルコードが動かないというのも変なので、このやり方は正しくないのかもしれない。(気味が悪い。)
なお Maple 3.1.1 の DIContainer.class.php には、COMPONENT_DIR が記述されているので Maple 3.2.0 では意図的に削除したものだと思われる。
このため Maple 3.2.0 では dicon.ini 側(など)で基準となるディレクトリ(COMPONENT_DIR)を記述できるようになっているのかもしれないが、今は深く追求しない事とする。
今回は maple 3.2.0 で Smarty を使用できるようにする。
なお現在のトップレベルのディレクトリー構成は以下の通りである。htdocs, maple, webapp 以下のディクレクトリー構成は省略する。
temp -+- htdocs
|
+- maple
|
+- webapp
「maple」ディレクトリに「smartyのlibs」ディレクトリーをコピーし、「libs」を「smarty」にリネームする。
なお、前記リネームした「smarty」は、「webapp\config\maple.inc.php」に定義されている定数 SMARTY_DIR に合わせておけば任意のディレクトリー名で構わない。
「maple\core\SimpleView4Maple.class.php」における23行目(近辺)の
require_once "Smarty.class.php";
を
require_once SMARTY_DIR . "/Smarty.class.php";
に変更する。
Smartyが正しく動作しているかについては、以下の手順で確認することができる。
例えば「htdocs\example1.php」における46行目(近辺)の
define('DEFAULT_ACTION', 'examples_simple_example1_page1');
を
define('DEFAULT_ACTION', 'examples_smarty_example1_page1');
に変更し、ブラウザから「example1.php」にアクセスする。
正しく動作している場合には、Smartyを使用していない場合と同じ画面が表示される。逆に画面が真っ白になる場合には設定に誤りがあると思われる。
なお現在のトップレベルのディレクトリー構成は以下の通りである。htdocs, maple, webapp 以下のディクレクトリー構成は省略する。
temp -+- htdocs
|
+- maple
|
+- webapp
「maple」ディレクトリに「smartyのlibs」ディレクトリーをコピーし、「libs」を「smarty」にリネームする。
なお、前記リネームした「smarty」は、「webapp\config\maple.inc.php」に定義されている定数 SMARTY_DIR に合わせておけば任意のディレクトリー名で構わない。
「maple\core\SimpleView4Maple.class.php」における23行目(近辺)の
require_once "Smarty.class.php";
を
require_once SMARTY_DIR . "/Smarty.class.php";
に変更する。
Smartyが正しく動作しているかについては、以下の手順で確認することができる。
例えば「htdocs\example1.php」における46行目(近辺)の
define('DEFAULT_ACTION', 'examples_simple_example1_page1');
を
define('DEFAULT_ACTION', 'examples_smarty_example1_page1');
に変更し、ブラウザから「example1.php」にアクセスする。
正しく動作している場合には、Smartyを使用していない場合と同じ画面が表示される。逆に画面が真っ白になる場合には設定に誤りがあると思われる。
maple 3.2.0では自身の環境で「example2.php」と「example6.php」が動作しないので、maple 3.1.1を動作させて見て分かったのがSmartyのデバッグコンソールのようなものが、mapleにもある事である。
3.1.1では、サンプルコードを動作させると、自動的にデバッグコンソールが起動されるようになっていた。
3.1.1では、デバックコンソールの表示、非表示は例えばexample1の場合、「example1.php」で定数 DEBUG_MODE の値を変更する事により表示・非表示を制御している。
非表示とするには「define('DEBUG_MODE', 0);」と記述すれば良い。なお未定義の場合には、(断片的にソースを見てみた所)どこかで「DEBUG_MODE」に1を設定する箇所があったので、未定義の場合でもデバッグコンソールが表示されてしまう。
一方、3.2.0では、3.1.1用のサンプルコードそのものをコピーしただけでは、デバックコンソールは表示されない。
更新履歴を見ると3.2.0からはデバックコンソールは、DEBUG_MODE という定数で表示、非表示を制御しなくなったようである。
Maple Wikiを読む限りフィルターとして実装されているので、maple.iniでデバックフィルターを適用してやれば、デバックコンソールが起動するのではないか?と思い設定を色々試してみた。
結論としては、maple.ini に以下の記述を追加する事によりデバックコンソールが起動するようになった。
[GlobalFilter]
Debug =
[Debug]
自身が上記設定を追加したのは、「webapp/modules/maple.ini 」であるが、適用させたいモジュールの maple.ini にのみ上記設定をすれば、該当モジュールを読み込んだ時にだけデバックコンソールが起動するものと思われる。
なお、maple 3.1.1 ではデバックコンソール内に表示される日本語が文字化けしていたが、maple 3.2.0 では正常に表示される事も分かった。
どこで読んだか(記憶)不明ではあるが、あるバージョンから [GlobalFilter] に記述しなくてもフィルターが起動できるようになったとか、という感じの記事を読んだ記憶があるので、[GlobalFilter]Debug= を省略してみたが、省略するとデバックコンソールは起動できなかった。
[2008.2.11追記]
フィルターの設定方法については、ここの「設定ファイルの仕様」−「maple.ini」が参考になる。
この内容を見れば何故、上記の条件で [GlobalFilter] が何故必要になるか理解できる。
3.1.1では、サンプルコードを動作させると、自動的にデバッグコンソールが起動されるようになっていた。
3.1.1では、デバックコンソールの表示、非表示は例えばexample1の場合、「example1.php」で定数 DEBUG_MODE の値を変更する事により表示・非表示を制御している。
非表示とするには「define('DEBUG_MODE', 0);」と記述すれば良い。なお未定義の場合には、(断片的にソースを見てみた所)どこかで「DEBUG_MODE」に1を設定する箇所があったので、未定義の場合でもデバッグコンソールが表示されてしまう。
一方、3.2.0では、3.1.1用のサンプルコードそのものをコピーしただけでは、デバックコンソールは表示されない。
更新履歴を見ると3.2.0からはデバックコンソールは、DEBUG_MODE という定数で表示、非表示を制御しなくなったようである。
Maple Wikiを読む限りフィルターとして実装されているので、maple.iniでデバックフィルターを適用してやれば、デバックコンソールが起動するのではないか?と思い設定を色々試してみた。
結論としては、maple.ini に以下の記述を追加する事によりデバックコンソールが起動するようになった。
[GlobalFilter]
Debug =
[Debug]
自身が上記設定を追加したのは、「webapp/modules/maple.ini 」であるが、適用させたいモジュールの maple.ini にのみ上記設定をすれば、該当モジュールを読み込んだ時にだけデバックコンソールが起動するものと思われる。
なお、maple 3.1.1 ではデバックコンソール内に表示される日本語が文字化けしていたが、maple 3.2.0 では正常に表示される事も分かった。
どこで読んだか(記憶)不明ではあるが、あるバージョンから [GlobalFilter] に記述しなくてもフィルターが起動できるようになったとか、という感じの記事を読んだ記憶があるので、[GlobalFilter]Debug= を省略してみたが、省略するとデバックコンソールは起動できなかった。
[2008.2.11追記]
フィルターの設定方法については、ここの「設定ファイルの仕様」−「maple.ini」が参考になる。
この内容を見れば何故、上記の条件で [GlobalFilter] が何故必要になるか理解できる。
「example5.php」については、設定によっては、PHP5との組み合わせでエラーが発生してしまう事が分かった。3.1.1付属のサンプルそのものでは問題が発生しないが、例えば以下のように設定を変更するとエラーが発生してしまう。
試しに以下のファイルの
webapp\modules\examples\simple\example5\done\maple.ini
16行目付近にある
noFileError = "すべてのファイルを指定してください。"
を
noFileError[2] = "ファイル2を指定してください。"
に変更してみた。
すると以下のようなワーニングが表示された。
「Warning: Error parsing ・・・webapp/modules/examples/simple/example5/done/maple.ini on line 14 in ・・・maple\core\ConfigUtils.class.php on line 228
」
これはPHP5とPHP4とで parse_ini_file()関数の仕様が完全には統一されていないのが原因のようで、配列形式で上記設定ファイルを記述すると、正しく設定ファイルを読み込めずにエラーが発生するようである。
ここに本現象に関するコメントがあるが、「PHP4のparse_ini_file関数と同じような動作をする関数を自作して」というリンクが切れているのと、「PHPのバージョン見て動作を切り替えるしか無さそうですね。近日中に対処します。 -- Hawk? 2005-06-14 20:17:55 (火) 」と書かれているものの、2008年になっても対処されていないようので、どうしても配列形式で記述したい場合には、使用する人が自分で対処するしかなさそうだ。
試しに以下のファイルの
webapp\modules\examples\simple\example5\done\maple.ini
16行目付近にある
noFileError = "すべてのファイルを指定してください。"
を
noFileError[2] = "ファイル2を指定してください。"
に変更してみた。
すると以下のようなワーニングが表示された。
「Warning: Error parsing ・・・webapp/modules/examples/simple/example5/done/maple.ini on line 14 in ・・・maple\core\ConfigUtils.class.php on line 228
」
これはPHP5とPHP4とで parse_ini_file()関数の仕様が完全には統一されていないのが原因のようで、配列形式で上記設定ファイルを記述すると、正しく設定ファイルを読み込めずにエラーが発生するようである。
ここに本現象に関するコメントがあるが、「PHP4のparse_ini_file関数と同じような動作をする関数を自作して」というリンクが切れているのと、「PHPのバージョン見て動作を切り替えるしか無さそうですね。近日中に対処します。 -- Hawk? 2005-06-14 20:17:55 (火) 」と書かれているものの、2008年になっても対処されていないようので、どうしても配列形式で記述したい場合には、使用する人が自分で対処するしかなさそうだ。
これで他のサンプルコードも動作するかと思いきや、「example2.php」と「example6.php」は正常に動作しなかった。
「example2.php」と「example6.php」については、「DIContainer」というものを使っている所でエラーが発生しているようである。「DIContainer」は「dicon.ini」から必要な情報を取得するようなのだが、「dicon.ini」のセクション名と、Maple3.2.0のモジュール構成が違うのか?それとも必要なモジュールが入っていないのか現時点では不明であるが、今はスルーしておくことにする。(「DIContainer」の意味が良く分かっていないので。)
なお、maple 3.1.1では「example2.php」と「example6.php」も正常に動作していた。3.1.1用のサンプルコードなので当り前ではあるが。だが、この過程でmapleにデバックコンソールがある事が分かったのは収穫であった。デバックコンソールについては別途記事を書く事にする。
「example2.php」と「example6.php」以外のサンプルコードは、正しく動作しているようである。
ただし、「example5.php」については、設定によっては、PHP5との組み合わせでエラーが発生してしまう事が分かった。
これについては次の記事に書く事にする。
「example2.php」と「example6.php」については、「DIContainer」というものを使っている所でエラーが発生しているようである。「DIContainer」は「dicon.ini」から必要な情報を取得するようなのだが、「dicon.ini」のセクション名と、Maple3.2.0のモジュール構成が違うのか?それとも必要なモジュールが入っていないのか現時点では不明であるが、今はスルーしておくことにする。(「DIContainer」の意味が良く分かっていないので。)
なお、maple 3.1.1では「example2.php」と「example6.php」も正常に動作していた。3.1.1用のサンプルコードなので当り前ではあるが。だが、この過程でmapleにデバックコンソールがある事が分かったのは収穫であった。デバックコンソールについては別途記事を書く事にする。
「example2.php」と「example6.php」以外のサンプルコードは、正しく動作しているようである。
ただし、「example5.php」については、設定によっては、PHP5との組み合わせでエラーが発生してしまう事が分かった。
これについては次の記事に書く事にする。
前回は「Notice: Only variable references should be returned by reference in ・・・・\maple\core\Controller.class.php on line 120」が発生するところまで書いたので、正しく動作させるための変更方法について記述する。
結論から言えば、以下を修正した所、正常に動作するようになった。
・ファイル名: webapp\config\maple.inc.php
・該当行: 130行目(近辺)
・該当コード(変更前): define('BASE_INI', WEBAPP_DIR . '/config/base.ini');
・該当コード(変更後): define('BASE_INI', '/config/base.ini');
これで example1.php が正常に動作するようになった。
結論から言えば、以下を修正した所、正常に動作するようになった。
・ファイル名: webapp\config\maple.inc.php
・該当行: 130行目(近辺)
・該当コード(変更前): define('BASE_INI', WEBAPP_DIR . '/config/base.ini');
・該当コード(変更後): define('BASE_INI', '/config/base.ini');
これで example1.php が正常に動作するようになった。
2008.2.5現在の最新安定バージョンは3.2.0で、ここからダウンロードできる。
ダウンロードして思った事。サンプルコードがない。
そこで旧バージョン3.1.1をダウンロードして見ると、これにはサンプルコードが付いているので、3.1.1のサンプルコードを3.2.0で動作させて見ることにした。
なお、3.1.1のサンプルコードはexample1〜example6までのサンプルコードがあった。
サンプルコードはともかく、とりあえず maple をインストールして見る。
インストール方法についてはこららに書かれているので、これを参考にインストールして見ることとした。
今回はコマンドを使わずにインストールしてみた。ダウンロードした圧縮ファイルを展開すると
「Maple-3.2.0」というディレクトリ内に、いくつかのサブディレクトリが存在する。
前記「Maple-3.2.0」を「maple」(全て小文字)にリネームし、「maple」ディレクトリを仮想ディレクトリ内の任意のディレクトリにコピーすれば終わりだ。
(手順書はinclude_path内に「maple」ディレクトリをコピーするようになっているが、特にinclude_path内にコピーする必要はないようだ。レンタルサーバーなどに移植する事を想定して、include_path内ではなく任意のディレクトリにコピーし動作させる事とした。)
次に Maple の動作確認をするために、3.1.1用のサンプルコードをコピーする。
3.1.1の圧縮ファイルを展開すると「maple-3.1.1」というディレクトリ内にいくつかディレクトリが存在する。その中から「htdocs」と「webapp」ディレクトリを、前記「maple」ディレクトリと同一階層にコピーする。
先ほど、「maple」ディレクトリを任意のディレクトリにコピーしたが、任意のディレクトリ名を「temp」とすると、「temp」ディレクトリ内に「htdocs」と「webapp」をコピーすれば良い。
これにより「temp」ディレクトリ内には、「maple」, 「htdocs」, 「webapp」の3つのディレクトリが存在する事になる。
「htdocs」ディレクトリ内には「example1.php」〜「example6.php」が入っているので、ブラウザから試しに「example1.php」にアクセスし以下のような画面が表示されれば正しくインストールできている。(と思われる。)

しかし、自分の環境においては以下のような注意が表示されてしまった。
「Notice: Only variable references should be returned by reference in ・・・・\maple\core\Controller.class.php on line 120」
ダウンロードして思った事。サンプルコードがない。
そこで旧バージョン3.1.1をダウンロードして見ると、これにはサンプルコードが付いているので、3.1.1のサンプルコードを3.2.0で動作させて見ることにした。
なお、3.1.1のサンプルコードはexample1〜example6までのサンプルコードがあった。
サンプルコードはともかく、とりあえず maple をインストールして見る。
インストール方法についてはこららに書かれているので、これを参考にインストールして見ることとした。
今回はコマンドを使わずにインストールしてみた。ダウンロードした圧縮ファイルを展開すると
「Maple-3.2.0」というディレクトリ内に、いくつかのサブディレクトリが存在する。
前記「Maple-3.2.0」を「maple」(全て小文字)にリネームし、「maple」ディレクトリを仮想ディレクトリ内の任意のディレクトリにコピーすれば終わりだ。
(手順書はinclude_path内に「maple」ディレクトリをコピーするようになっているが、特にinclude_path内にコピーする必要はないようだ。レンタルサーバーなどに移植する事を想定して、include_path内ではなく任意のディレクトリにコピーし動作させる事とした。)
次に Maple の動作確認をするために、3.1.1用のサンプルコードをコピーする。
3.1.1の圧縮ファイルを展開すると「maple-3.1.1」というディレクトリ内にいくつかディレクトリが存在する。その中から「htdocs」と「webapp」ディレクトリを、前記「maple」ディレクトリと同一階層にコピーする。
先ほど、「maple」ディレクトリを任意のディレクトリにコピーしたが、任意のディレクトリ名を「temp」とすると、「temp」ディレクトリ内に「htdocs」と「webapp」をコピーすれば良い。
これにより「temp」ディレクトリ内には、「maple」, 「htdocs」, 「webapp」の3つのディレクトリが存在する事になる。
「htdocs」ディレクトリ内には「example1.php」〜「example6.php」が入っているので、ブラウザから試しに「example1.php」にアクセスし以下のような画面が表示されれば正しくインストールできている。(と思われる。)

しかし、自分の環境においては以下のような注意が表示されてしまった。
「Notice: Only variable references should be returned by reference in ・・・・\maple\core\Controller.class.php on line 120」
PHPのフレームワーク Maple を初めて使う事になったので、設定方法などについて個人的に備忘録としてメモして行く事とする。
今回インストールする環境は以下の通りである。
・OS: Windows XP
・HTTP Server: Apache 2.2.4
・PHP: 5.2.3
なお、ApacheやPHPは 「XAPP 1.63a」で一括してインストールしたものである。
今回インストールする環境は以下の通りである。
・OS: Windows XP
・HTTP Server: Apache 2.2.4
・PHP: 5.2.3
なお、ApacheやPHPは 「XAPP 1.63a」で一括してインストールしたものである。































