maple : 自作 Filter の取り扱い

PHP で提供する新たな Web アプリケーションを maple を使用して構築しようと、maple についてアレコレと模索しているところなのですが、どうもうまい事いかないなあというか、出来るのかもしれんけどどうなんだろうという点、まあ正直に言うとまだ良く分かってないという事実でありますのでここいらでチラシの裏に書いてちょっと落ち着いて考えようというお話です。

maple で提供されている FilterChain / ActionChain にて自分で用意した Filter を使用する場合、その記述したファイルを maple/filter ディレクトリ以下に置くしか方法はないのではないかと。この点についての真偽も定かではない状態なのですが、どうしてこの部分に引っかかるのかというと、

(1) maple ディレクトリは maple からデフォルトで提供される機能の集まりであり、つまりとんでもない問題が発覚してリリース前に緊急で patch をあてる以外に中身をいじることはなく、また正式リリースは行われていないものの取り込まれる予定であるファイルでもない限り、ファイルの追加も行わない。極端にいえば /usr/local/share 以下にパッケージとして設置するくらいの勢いで扱いたい。実際 Smarty などは /usr/local/share/php/Smarty という形で設置、使用している。

(2) webapp ディレクトリは maple を使用した Web アプリケーションの module などを集める。maple に依存するプログラム (上記の自作 Filter など) も webapp/filter のような形で設置する。

(3) maple を始めとするフレームワークに依存しないが Web アプリケーションのサービスに関連するプログラム (Web アプリケーションにおけるデータアクセス層などのプログラム) は webapp と同列の別途ディレクトリへ。

という思いがあるからです。

既に maple で自作 Filter を maple/filter 以外の好きなところに設置して FilterChain ができるのであればただの知識不足でした面目ないガハハな話ですが、ぱっと見たところ今は無理っぽいと思うのですがどうでしょうか。(1) にような振る舞いをやめて通常ディレクトリ構成どおり maple ディレクトリも webapp と同列に設置してしまえば解決はします。/usr/local/share/php/maple のようにおいてしまうとバージョンアップによる動作の違いが過去提供したサービスに出る可能性も確かにあります。でも各サービス（apache のバーチャルホスト毎）に maple ファイル群を置くのもどうかなあと思うわけです。

もし仮に maple に手を加えてこの話を解決しようとした場合。設定ファイルに Filter を記述しますが、その Filter が maple 提供なのか自作物なのかの区別を行わなければならなくなります。default_filter = true とか false とかか。デフォルトは true で 自作物のみ記述とか。わーなんかアレだなあ。

他サービスでも利用できるような自作 Filter は素直に maple ディレクトリ以下に置いてもいいとは思いますけどね。そのサービスでのみしか使用しない（できない）けど各 Action でそのフローを呼び出しすら書きたくなくて GlobalFilter として一枚かましたいことってあるはず。あるかな？認証とか。それもうまいこと書けるのかな。

どんなもんなのかなあ。