Kazuhiko
kazuh****@fdiar*****
2009年 8月 1日 (土) 21:06:14 JST
かずひこです。 大変遅くなりましたが、ようやく、okkezさんのHiki on Rackパッチを読みました。 http://sourceforge.jp/projects/hiki/lists/archive/dev/2008-November/001244.html 須藤さんが指摘しているように、いろんな変更が混在しているので、それぞれの 変更ごとに、マージするとかしないとかいつするとかの方針を相談していきま しょう。 * escape_htmlとか escapeHTMLだろうがescape_htmlだろうが、Stringクラスにメソッドを追加する のには抵抗があります。 http://www.cozmixng.org/retro/projects/hiki/changesets/939 で、Pluginクラスに"include ERB::Util"していますので、プラグインではh()と かをどうぞ、でいいのではないでしょうか？ プラグイン以外でも、ERB:: Util.hを呼ぶなりincludeするなり、かなぁ。 もちろん、従来存在するAPIは互換性のために今後も必要です。 同様に、Time.rfc1123の追加とかも抵抗があります。 * 明示的なreturnの追加 okkezさんが「明示的な return の追加は、自分には無いと分かりにくいと判断 したためです。」と感じた場所にだけ追加されているようですし、私もそう思い ますし、コードのメンテナンス性がマシになると思うので、これに関してはいつ でもコミットしてください。 * Rack対応 ** @cgiから@requestへの置き換え > 一般的な Rack のアプリに合わせて @cgi ではなくて @request という変数を > 使うようにした関係でサードパーティ製のプラグインがうごかない可能性があります。 > # 一応、プラグイン側は @cgi なままでも動くようにしたつもりですが、あまり自信ありません。 「プラグイン側は @cgi なままでも動く」ためのコードが見当たらない気がしま すが、私の勘違いでしょうか？ Rack的にそっちが普通、というのは分かるのですが、無駄に差分が大きくなるの で、どうしても必要でなければ当面はパスでお願いします。それよりも、 > rack と cgi で色々と違うので、Hiki::Request と HIki::Response を作成して > 互換レイヤーを導入するとよいと思います。 がいいと思いますので。 ** プラグインの互換性 @cgiのAPIの問題は、上記のような互換レイヤーでどうにかなるかもしれません が、「プラグイン内部で直接printしているのは止める」あたりになると、プラ グインの非互換は避けられないように思います。 0.8.7→0.8.8のバージョンアップで（自家製）プラグインが非互換、というのは 避けたいので、非互換が出そうな時点で、v0_8ブランチを切って、0.8.8をさっ さとリリースした上で、1.0目指してゴー！でどうでしょうか？ かずひこ
