ちょっと前に#!shebang.jpさんが「Sledgeで気になるとこ」というエントリを書いてましたが、これに被せる形で、Sledge2で個人的にやりたいと思ってるものを書いてみたいと思います。
- Sledge::Helperを導入 qootas.orgのせきむらさんが作ってらっしゃったSledge::Helperをマージしたいなぁ。
- Pagesをもうちょっと実際のページ生成ロジックと離したい Sledgeで開発していて困るのが、Pagesに書いたコードをスクリプトから呼びたいときなどむりくりやらなければならない。なぜならSledgeはビジネスロジックがほぼPagesと等価となっているからである。そこをもう少し離してやりたい。
- redirectのあとのコードを実行しないように にぽたん研究所所長も、#!shebang.jpの方も言ってましたが、だれもが思うところですね。現状のSledgeでは、Pagesで$self->redirect('/foo');とやったあともコードが実行されてしまいます。それをどうにかしたし。バグの温床にもなりやすいですし。
- プラグインの機構を盛り込みたい 現状Sledgeのプラグインは import ベースなものが多いです。たしかにこれはperlの利点なんだけど、importとか使わなくても最初からプラグインを追加できる機構を盛り込みたいなと思います。個人的には、CatalystのNEXTみたいなやつカッコイイななんて思います。チェイン オブ レスポンシビリティ？(よくわかってない…)
今のところ思うところはこんな感じです。
＃思い付いたものを貯めこまないで、排出してみるベースで書きました。
Sledge2 とは関係ないですが、mod_rewrite と Sledge::Dispatcher を一緒に使うと、期待通りの動きをしてくれないです。
Project::Dispatcher 作ってごにょごにょっと対応してますけど、こういうネタは ML の方が良いのかな。
あーそういう場合があるかも。
例えばどんなときですかね？
DynamicとPropertiesどっちつかってます？
Dynamicは結構挙動が制限されるので微妙っちゃ微妙ですね。
RewriteRule ^/foo/(.*) /foo?key=$1
というルールで
/foo/bar
にアクセスしたとき、
Hoge::Pages::Index->new->dispatch('foo');
となってほしいのに
Hoge::Pages::Foo->new->dispatch('bar');
になってしまいますね。
仕方ないので、
RewriteRule ^/foo/(.*) /foo?key=$1 [E=REWRITED_URI:/foo]
とかってやって
Hoge::Dispatcher
作って
my $uri = $ENV{REWRITED_URI} || $r->uri;
とかって無理やりやっていて、かなりきもいです。
ちなみに Dynamic です。
RewriteRule ^/foo/(.*) /foo?key=$1
ってやると、mod_rewriteでマッチはしていて、一応/fooをみつけにいくんですけど、ディレクトリ(もしくはファイル)を見にいってしまって、でもそんなディレクトリ(もしくはファイル)はないので元の/foo/barを表示しちゃう感じですね。
上記のような使い方をしていないのであれなんですが、もしやるとしたらapacheをreverse proxyとwebappという役割毎に2つ立ち上げて、reverse proxy側でやるべきじゃないかなと思います。
解決にはなってませんが…。
どうもです。
たしかに reverse proxy 側でやれば問題なしですね。