S2Base.PHP5用のamfphpプラグインであったらいいな、なコマンドをまとめておきましょう。
既存のコマンド
全部ないと作業になりません。
独自コマンド
プロジェクトのイニシャライズコマンド
S2Baseの組み込みプラグインではないので、s2baseコマンドでプロジェクトを作成した後にamfphpプラグイン用にプロジェクトの初期化を行うコマンドが必要ですね。
要件はこんな感じかな。
- 公開用ディレクトリ作成
- クライアントアプリケーション用ディレクトリ作成
- amfphp設定用diconを/app/commmons/diconディレクトリにコピー
Gateway作成コマンド
公開用ディレクトリにエントリポイントとなるGatewayを出力するコマンド。
多分、一番の肝。
一緒にクライアントアプリケーション用のservices-config.xmlを出力すると、より幸せになれそう。
Gatewayの出力対象は、Module毎。
複数Moduleがあるプロジェクトの場合は、エントリポイントが変わる。
つまりservices-config.xmlのchannel-definition要素を複数にする必要がある。
後はdiconファイルをincludeしてる場合に、同じdiconをincludeしたらどうなるのか、とか。
一番スマートなのはdiconディレクトリにあるdiconファイルを全部読んで、DOMでもにゃもにゃして、同じ要素をはじいてincludeなしのdiconファイルを作るのが一番かな。
- モジュール内のdiconファイルを統合して、ひとつのdiconファイルにまとめる。(ファイル名を指定可能にする。)
- 指定したモジュールに該当するGatewayを指定された名前で出力。
- services-config.xmlの出力。(または更新)
クライアントアプリケーション用Entity作成コマンド
これがないと、プラグインを作る意味なし。
指定されたモジュールのentityディレクトリに定義されたEntityたちのActionScript実装をクライアントアプリケーション用ディレクトリに出力。
データ型まで設定できるとよかったんですが、今のところちょっと難しそう。
RemoteClassメタデータタグと、CairngormのマーカインターフェースIValueObjectを組み込めるように。
それからyui-frameworksにも対応したいですが、特別な何かがあるか調査。
- 対象ModuleとEntityを指定可能にする。
- 出力先のパッケージを指定可能にする。(複数階層あり)
- CairngormのIValueObjectのimplementsするかどうか質問する。
- Entity名を指定できるようにする。
- RemoteClassメタデータタグを出力する。
クライアントアプリケーション用Service作成コマンド
これもないと、プラグインを作る意味なし。
S2BaseのServiceに対応するクラスを作る。
できればActionScriptで作りたいところですが、メソッドまで含めるとなるとMXMLのmx:RemoteObjectタグmx:methodを使う方法しかない･･･のか？要調査。
後は引数の型をどうするか、ですね。
Entityが引数ならどうにかなりそうですが、Stringとかそういう場合。これも要調査。
あと戻り値とかどうなってるんだっけ、ということで要調査。
- 対象ModuleとServiceを指定可能にする。
- 出力先のパッケージを指定可能にする。(複数階層あり)
- メソッド、引数、(戻り値)も出力する。
その他、こんなのは？
例えばCairngormのServiceLocatorを出力する･･･とか、あってもなくてもいいぐらいのものですね。ひとまず保留。
他は･･･別に思いつきませんね。
要調査項目
文字通りの覚書サイトらしくなってまいりました。
とても人様に公開するような内容ではないですね。
diconファイルのすてきな統合方法
Gatewayを作る場合に参照するdiconファイルをどうするか。
複数のS2Containerは作りたくないですから、1Gatewayについて1diconファイルが原則というルールで行きたいです。
それにエントリポイントが複数あるという状態も、クライアントからしてみれば、めんどくさいのでちょうどいいGatewayの単位としてはS2BaseのModule単位というのが妥当だと思われます。
以上の理由で、Gateway作成時には、Moduleで定義されているdiconファイルと共通のdiconファイル(pdo.diconとかdao.diconとかamfphp.dicon)とかをくっつけたdiconファイルを作って、それをS2Containerに食べさせるのがよさげです。
普通に考えられるシーケンスとしては、こんな感じかな。
- 出力するGateway(統合diconファイル名と同じとする。)の名前を指定してもらう。(デフォルトはModule名)
- Moduleのdiconディレクトリにあるdiconファイルをリストして、統合するものをカンマ区切りで入力してもらう。(デフォルトは*Test*なもの以外全て)
- 指定されたdiconファイルを全部読み込んで、重複するコンポーネント定義を除く。
- 統合diconファイル出力。
大切なのは、どういう条件でコンポーネントが重複しているとみなすか、と実際に出力するdiconファイルの内容です。
重複の条件もそうですけど、出力する内容も問題です。
pdo.diconとamfphp.diconだけをincludeして、他はcomponentタグで、とかいうと同様の内容を定義したdiconファイルが複数できることになりますから、管理していく上で楽そうなのは指定されたdiconファイルを全部includeする･･･とか。
そうするとincludeタグが重複しそうなのですが、そうなった場合どういう動作になるのか、を調べないとですね。
RemoteObjectのサブクラスってMXMLでしか作れない？
決してそんなことはないんですけどね。
一般的にMXMLで書かれたものより、ActionScriptで書かれたものの方が動作が速いと会った気がします。
MXMLを使う場合は、mx:RemoteObjectタグのmx:methodタグでメソッド定義ができるんですが、ActionScriptで作る場合はどうするのかが、いまいち分りません。
mx.rpc.remoting.mxml.RemoteObjectのoperationsプロパティが多分それだと思うんですが、Flex2リファレンスガイドによると
通常、Operations 配列は MXML タグを使ってサービスを作成した場合に、MXML コンパイラによってのみ設定されます。
なんだそうです。「のみ」なのですか？
実際にはどうなるか試してみる必要があります。
変数や引数や戻り値の型、どうしましょうか
一番頭が痛い問題です。
Serviceのアクションスクリプトサイドを作る場合とEntityのアクションスクリプトサイドを作る場合に、型の指定をどうするべきなのか、ということです。
例えばEntityの場合、オリジナルはPHPの実装なのでプロパティの型が分らないんです。S2Dao型のEntityでSetterが指定されているなら、Setterの引数がTypeHintingで書かれているなら･･･取れますね。
そんなケースめったにないでしょうけど。しかもPHPのTypeHintingってobject型やarray型だけみたいですし。
DBMSから型が取れないかなとも思いましたが、ちょっといまいちっぽい感じです。
Serviceについては、Entityを引数にとる場合ならTypeHinting前提ですが、型をつけることができそうです。
(というか、それ以外は型が取れない。というのが正しい表現。)
型を意識しないのがPHPの利点で、型指定のある言語に移行する場合は一番の難点。
何ができるか、をよくよく考えて見ます。
以上、色々考えることがたくさんですね。
へろへろ調べてまいりましょう。