CAP::DebugScreenのアンケート - Hatena::Diary::Neko::kak 500 Internal Server Error
と、言うほどではないのですが。。。 ViewエンジンでTTが使えるように HTMLを利用者が指定したHTMLに置き換えることができる 上記２点ですがどう思いますか？ Debug用途のPluginだから１は必要ないかなと思ってるのですが、 ２をやるとするとテンプレートをTTで書きたい。 となると１を実装する必要あるんですよね。 そこまでやる必要あると思いますか？ 要望が多ければ実装してもいいなと思います。 Kenichi IshigakiさんのCGI-Carp-DebugScreenの場合は、 Viewが一定しないから複数Viewエンジンをサポートされてますが、 CGI::Appの場合はHTML::Templateだけでいいのかなと思ってしまいます。 CGI::Carp::DebugScreen::Dumperはちょっと面白いなと思いました。 ログ/画面（むしろ画面）に変数をダンプするのが楽
なぜ「CGI::AppはNEXTでぐりぐりって感じゃ無い方がいいと思ふ。」かについて - Hatena::Diary::Neko::kak 500 Internal Server Error
しょうもないタイトル＆内容ですが。。＾＾； CatalystなりDBIx::Classなりは継承継承しまくりで多重継承なんのそので、 NEXTやらClass::C3やらでゴリゴリメソッド実行。 何がなんやらわけわかめになりやすいでつ。 できる人がみればなんの抵抗も無くソース嫁て問題ないのでしょうが、 オイラみたいななんちゃってだとソース読むのにも一苦労なのですわ。 NEXTとかClass::C3の考え方ってすごいと思います。 でもCGI::Appはより簡単に汎用的に扱えるフレームワークであってほしいと思うのですわ。 そう考えると、現在の各Pluginで利用されているimportメソッドで動的にメソッド追加ってのが 理解しやすいのですよね。 全部が全部Railsを目指す必要ないし、Catalyst目指す必要ないですわ。 いいものは取り入れればよいし、そうでないものは捨てればいいし。 なのでM
CGI::Application::Dispatch v2.00_01 : blog.nomadscafe.jp
CGI::Application::Dispatch v2.00_01 CGI::ApplicationのMLでCGI::Application::Dispatchのv2.00_01がでてます。 svnで取得できます。 svn://svn.cromedome.net/CGI-Application-Dispatch 新しいdispatch tableがいい感じ。 今までは、PATH_INFOが /Module/Runmode で固定でしたが、これをいじる事ができます。 dispatchのカスタマイズをするにはCGI::Application::Dispatchを継承してdispatch_argsをoverrideします。 package MyApp::Dispatch; use base 'CGI::Application::Dispatch'; sub dispatch_args { r
にぽたん休憩所 - パクリ疑惑について
パクリ疑惑の話題を深く掘り下げて。 CMS researcher - Catalyst: スタックトレースをデバッグスクリーンに表示するプラグインを試す パクリ疑惑の話題を少しだけ。 Sledgeでスタックトレースをソースコードと一緒に出力するコードをid:nipotanさんが書かれたのですが、Catalyst::Plugin::StackTraceのコードの中にid:nipotanさんのコードとよく似ているコードを見つけました。Catalyst::Plugin::StackTrace::_print_context()のコードと、id:nipotanさんのコードを比較してみましょう。ほとんど同じです。 Catalyst::Plugin::StackTraceの作者が、id:nipotanさんのコードをパクッたの？そんなバカな？と思い、少し調べてみると、両方とも、CGI::Applicat
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
