From suzuki ＠ spice-of-life.net Thu Apr 21 23:40:58 2005 From: suzuki ＠ spice-of-life.net (SUZUKI Tetsuya) Date: Thu, 21 Apr 2005 23:40:58 +0900 Subject: [cgikit-dev 1] test Message-ID: <6c529cf3da47435f9571a96c44f61ab2@spice-of-life.net> テスト From speakillof ＠ yahoo.co.jp Sat Apr 23 07:52:01 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Sat, 23 Apr 2005 07:52:01 +0900 (JST) Subject: [cgikit-dev 2] Document Message-ID: <20050422225201.44143.qmail@web2707.mail.mci.yahoo.co.jp> ドキュメントについてです。 CGIKitを利用する人のためのドキュメントは 現状のWikiで良いと思います。 こちらに関して2つ要望があります。 * サイドメニューの字を大きくして欲しいです * コメントを挿入できるようにしませんか 1つ目は字が小さいとクリックしにくいからです(苦笑)。 2つ目はドキュメントのどこが分かりにくいといったフィードバックが 欲しいからです。hikiにはcomment.rbがあるので、 それで挿入可能になります。いかがでしょう? http://www.namaraii.com/hiki/?comment.rb 次はAPI Documentです。 英語版はRDocで良いと思います。 # RDocの生成するドキュメントは使いにくいと思うのですが、 # RDocを使うほうがriなどの周辺ツールを使って楽ができます。 日本語版はどうしましょうか? 鈴木さんはWikiに書くほうが良いと思われている? みたいですが、 問題があります。 * バージョンアップ バージョンアップの時の同期がしんどいです。 * トップページ、サイドメニュー 今のWikiのトップページ、サイドメニューは 初めて使う人のために最適化しています。 そのためAPI Documentにアクセスしたい人には不便です。 これは別のWikiを立ち上げてAPI Document用にするという方法 で対処可能ですね。 そういうわけでAPI Documentを書くのを少し待って、先に UIや形式等を決めませんか? 参考リンク Rubyのリファレンスマニュアルは使いにくいという評判なので、 それを反面教師にしましょう http://jp.rubyist.net/?CommentOnRubyHomePage 逆にphpのドキュメントは優れているので、 そのあたりを参考にしたいです 例 http://www.php.net/manual/ja/ref.calendar.php # 皮肉だなあ ついでにRailsのドキュメントの議論へのリンク http://wiki.rubyonrails.com/rails/show/DocumentationDiscussion サーチやコメントなんかは参考になります。 __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From suzuki ＠ spice-of-life.net Sat Apr 23 22:06:36 2005 From: suzuki ＠ spice-of-life.net (SUZUKI Tetsuya) Date: Sat, 23 Apr 2005 22:06:36 +0900 Subject: [cgikit-dev 3] Re: Document In-Reply-To: <20050422225201.44143.qmail@web2707.mail.mci.yahoo.co.jp> References: <20050422225201.44143.qmail@web2707.mail.mci.yahoo.co.jp> Message-ID: 鈴木です。 On 2005/04/23, at 7:52, speakillof wrote: > CGIKitを利用する人のためのドキュメントは > 現状のWikiで良いと思います。 > こちらに関して2つ要望があります。 対応しました。コメントのプラグインも入れたので確認してください。 > 次はAPI Documentです。 > 英語版はRDocで良いと思います。 了解です。 > 日本語版はどうしましょうか? > 鈴木さんはWikiに書くほうが良いと思われている? みたいですが、 > 問題があります。 ... > そういうわけでAPI Documentを書くのを少し待って、先に > UIや形式等を決めませんか? こちらも了解です。 日本語版もできればWebで読める形式にしたいです。 Railsのドキュメントの議論を読みましたが、ただWikiにするだけではだめですね。 ドキュメント管理アプリケーションを作ってしまうほうが早いのかも。 ----------------------------------- 鈴木鉄也 (SUZUKI Tetsuya) suzuki ＠ spice-of-life.net http://www.spice-of-life.net/ From speakillof ＠ yahoo.co.jp Sat Apr 23 23:53:35 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Sat, 23 Apr 2005 23:53:35 +0900 (JST) Subject: [cgikit-dev 4] =?iso-2022-jp?b?UmU6IENHSUtpdCAbJEIkTiVqJWobKEI=?= =?iso-2022-jp?b?GyRCITwlOSRLJEQkJCRGGyhC?= In-Reply-To: <3864b276a9db44c2246da89586135e0c@spice-of-life.net> Message-ID: <20050423145335.26396.qmail@web2701.mail.mci.yahoo.co.jp> cgikit-devに移ります。 > RHGの前にプレビューリリースを一度しておこうと思いますが、 > WEBrickのmultipartは未サポートにしておきましょうか？ 大きなファイルは扱えませんと明示しておけば良いと思います。 multipartをまったく扱えないわけではありませんから。 # RailsのWEBrick対応ってどうやっているんだろう? > Hashの場合のみkey, value属性を持つHashRepetitionにして、 > 通常のRepetitionでは任意の数のitem属性を使えるようにしたらどうでしょ う。 > each { |a, b, c, ...| } であれば、 > > :Object => { > :element => Repetition, > :list => :list, > :item1 => :a, > :item2 => :b, > :item3 => :c, > } > > など、３つのitem属性を使うようにします。 item1,2,3,4,5,6．．．となるわけですよね? 属性の名前がちょっと．．．。 これを実装する場合はHashRepetitionも Repetitionに含めてOKだと思いますが。 この仕様他の人の意見も聞かないと私には判断できません。 実装するにしても変更の可能性があることを 明示しておく必要があるでしょう。 > > Rubyで作るならwxWindowsとRubyCocoaで作るしかないのかもしれません。 > 各プラットフォーム共通のGUIは、実際には難しいですね。 > お互い別々に作ってみて、結果を見るのは面白そうです。 > > > wxWindowsではBrowser用のWidgetがあるんですが、 > > RubyCocoaではApplieのWebkitって使えるんですか? > > 使えます。ただ、WebKitでは特定のHTML要素や属性に対して > 独自の描画はできませんから、 > 簡単にはWebObjects Builderのようにできないですね。 > ドラッグ＆ドロップでコンポーネントを編集できなければ、 > エディタで直接編集するのと大差ないような気がします。 このあたりはwxWindowsも同じかもしれません。 でも、DnDした時に再ロードをかければ編集したように見せかけることが できると思います。 > emacsのcgikit-modeも、もっと面白い形にできると思うのですが、 > lispに不慣れなもので… 私もです。 cgikit-modeで メソッド名 <-> ckdの定義 <-> HTMLのエレメント を簡単に移動できると楽なんですけどね。 > > # DirectAction用のフレームワークも考えたいですね。 > > これ、CGIKit 1.xのときの方法が役に立つのではないかと考えています。 > 扱うデータを文字列、数値などに限定すれば、DirectAction時でも（ある程 度）自動的なフォーム処理を行えると思います。 # 1.xの記憶があまり残っていないのですが．．．。 私は ダイレクトアクションに引数をつけることを考えていました。 セッション(や認証)が必要無いという前提ですが、 Linkエレメント等にアクションの引数を設定します。 リンクの生成時にGETリクエストにPStore + escapse したデータ を貼り付けてダイレクトアクションの実行直前に引数を復元して 引数付きで実行するという形です。 もちろん、GETリクエストの文字数の制限と securityの問題がありますが、自分でごちゃごちゃした 値渡しをするより楽でしょう。 この場合、direct_action属性の拡張 もしくは 新しいエレメントが必要になります。 __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From speakillof ＠ yahoo.co.jp Sat Apr 23 23:57:05 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Sat, 23 Apr 2005 23:57:05 +0900 (JST) Subject: [cgikit-dev 5] Re: Document In-Reply-To: Message-ID: <20050423145705.99656.qmail@web2702.mail.mci.yahoo.co.jp> > > CGIKitを利用する人のためのドキュメントは > > 現状のWikiで良いと思います。 > > こちらに関して2つ要望があります。 > 対応しました。コメントのプラグインも入れたので確認してください。 ありがとうございました。 サイドメニューが結構大きいですね。ちょっとびっくりしました。 こちらの方が使いやすいかな? また、実際に使っている方の意見を聞いて修正しましょう。 > > そういうわけでAPI Documentを書くのを少し待って、 > こちらも了解です。 > 日本語版もできればWebで読める形式にしたいです。 > > Railsのドキュメントの議論を読みましたが、 > ただWikiにするだけではだめですね。 > ドキュメント管理アプリケーションを作ってしまうほうが早いのかも。 基本はWikiで良いのかもしれません。 で、ちょっと考えました。 * 基本はHiki + cvs(or CKWiki) にする。 文法はほとんど一緒なのでCKWikiでもOKでしょう。 * CGIKitのクラス名・メソッド名一覧を動的にrubyのプロセスから生成し、Hiki のドキュメント内にあるクラス名・メソッド名との差異を表示するページを作 る。このページで編集者にメソッド名やクラス名の変更を促す。 例えば、 CGIKit::Application のドキュメント が Hiki に存在していて、 バージョンアップによってクラス名が CGIKit::FooApplication に なった場合、差異を表示するページにアクセスすると、 左に CGIKit::Application が class doesn't exist と表示され、 右に CGIKit::FooApplicationが document doesn't exist と表示される という具合です。同様の事をメソッドや定数でも行います。 これを行うにはCGIKit関係のすべてのクラス/モジュール・メソッド・定数 がCGIKitの名前空間に存在しなければ実行できません。 * 配布用にはHTML or PDF(fpdfで生成?) or Wikiをローカルに立ててもらう(CKWiki ならこれが可能) * 全文検索やライブサーチを可能にする 全文検索は * namazu http://namazu.org/ * Rast http://www.netlab.jp/rast/ * Senna http://dev.razil.jp/project/senna/#label-3 * Estraier http://estraier.sourceforge.net/spex-ja.html のいずれかを使う。 ライブサーチは下のページが参考になります。 Ajaxを使ったリファレンスマニュアルのサーチです。 http://d.hatena.ne.jp/secondlife/20050203/1107371020 __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From suzuki ＠ spice-of-life.net Sun Apr 24 02:59:18 2005 From: suzuki ＠ spice-of-life.net (SUZUKI Tetsuya) Date: Sun, 24 Apr 2005 02:59:18 +0900 Subject: [cgikit-dev 6] Re: Document In-Reply-To: <20050423145705.99656.qmail@web2702.mail.mci.yahoo.co.jp> References: <20050423145705.99656.qmail@web2702.mail.mci.yahoo.co.jp> Message-ID: <1848036a7cedf33fc9fa65776262e74d@spice-of-life.net> 鈴木です。 On 2005/04/23, at 23:57, speakillof wrote: >> ドキュメント管理アプリケーションを作ってしまうほうが早いのかも。 > 基本はWikiで良いのかもしれません。 > > で、ちょっと考えました。 ... > * CGIKitのクラス名・メソッド名一覧を動的にrubyのプロセスから生成し、Hiki > のドキュメント内にあるクラス名・メソッド名との差異を表示するページを作 > る。このページで編集者にメソッド名やクラス名の変更を促す。 それは面白そうですね。ただ、Hiki/CKWikiと連携するよりは CKWikiをベースにドキュメント管理用のWikiを作るほうがやりやすそうです。 私はメソッドにカテゴリを設定してみたいです。 Rubyは言語仕様としてのカテゴリはサポートしていませんが、 単にメソッドがアルファベット順に並ぶより見やすいと思います。 CGIKit::Componentを例にすると、次のようなイメージです。 * 機能別にカテゴリをつける場合 - accessing application base_name ... - testing has_session? subcomponent? ... * ドメイン別にカテゴリをつける場合 - request-response loop take_values_from_request( request, context ) invoke_action( request, context ) append_to_response( response, context ) - template and declaration template_file declaration_file > * 配布用にはHTML or PDF(fpdfで生成?) or > Wikiをローカルに立ててもらう(CKWiki > ならこれが可能) PDFは無理ですが、HTMLを出力するならコンポーネントが使えますね。 > * 全文検索やライブサーチを可能にする ... > ライブサーチは下のページが参考になります。 > Ajaxを使ったリファレンスマニュアルのサーチです。 > http://d.hatena.ne.jp/secondlife/20050203/1107371020 参考にさせていただきます。 なんとかAjaxをエレメントに落とせるといいんですが。 ----------------------------------- 鈴木鉄也 (SUZUKI Tetsuya) suzuki ＠ spice-of-life.net http://www.spice-of-life.net/ From speakillof ＠ yahoo.co.jp Sun Apr 24 08:21:34 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Sun, 24 Apr 2005 08:21:34 +0900 (JST) Subject: [cgikit-dev 7] Re: Document In-Reply-To: <1848036a7cedf33fc9fa65776262e74d@spice-of-life.net> Message-ID: <20050423232134.51138.qmail@web2707.mail.mci.yahoo.co.jp> > On 2005/04/23, at 23:57, speakillof wrote: > >> ドキュメント管理アプリケーションを作ってしまうほうが早いのかも。 > それは面白そうですね。ただ、Hiki/CKWikiと連携するよりは > CKWikiをベースにドキュメント管理用のWikiを作るほうがやりやすそうです 。 CVSのところだけがネックですけど。 > 私はメソッドにカテゴリを設定してみたいです。 > Rubyは言語仕様としてのカテゴリはサポートしていませんが、 > 単にメソッドがアルファベット順に並ぶより見やすいと思います。 > CGIKit::Componentを例にすると、次のようなイメージです。 Hikiにはページごとの属性を付けることができますが、 それを活用するという形でしょうか? この場合、Wikiの一ページにつきメソッドの説明がひとつという形 を取ってもらえれば可能だと思います。 後は運用次第です。 > > * 配布用にはHTML or PDF(fpdfで生成?) or > > Wikiをローカルに立ててもらう(CKWiki > > ならこれが可能) > > PDFは無理ですが、HTMLを出力するならコンポーネントが使えますね。 CKWikiならいったん木構造に落ちているみたいなので、 fdpdfを使えば何とかなります。 問題は日本語ですが。 FPDF http://www.fpdf.org/ Ruby FPDF http://brian.imxcc.com/fpdf/ > > * 全文検索やライブサーチを可能にする > ... > > ライブサーチは下のページが参考になります。 > > Ajaxを使ったリファレンスマニュアルのサーチです。 > > http://d.hatena.ne.jp/secondlife/20050203/1107371020 > > 参考にさせていただきます。 > なんとかAjaxをエレメントに落とせるといいんですが。 これは何とかなるでしょう。 とりあえず私のほうでプロトタイプを作ってみます。 __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From speakillof ＠ yahoo.co.jp Sun Apr 24 13:53:03 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Sun, 24 Apr 2005 13:53:03 +0900 (JST) Subject: [cgikit-dev 8] Re: Document In-Reply-To: <20050423232134.51138.qmail@web2707.mail.mci.yahoo.co.jp> Message-ID: <20050424045303.73651.qmail@web2707.mail.mci.yahoo.co.jp> ちょっと考え直したので。 > > 私はメソッドにカテゴリを設定してみたいです。 > > Rubyは言語仕様としてのカテゴリはサポートしていませんが、 > > 単にメソッドがアルファベット順に並ぶより見やすいと思います。 > > CGIKit::Componentを例にすると、次のようなイメージです。 > Hikiにはページごとの属性を付けることができますが、 > それを活用するという形でしょうか? > > この場合、Wikiの一ページにつきメソッドの説明がひとつという形 > を取ってもらえれば可能だと思います。 > 後は運用次第です。 1ページにつきメソッドの説明が1つという形でなくても良いですね。 categoryの指定方法さえ決まれば処理できると思います。 > > なんとかAjaxをエレメントに落とせるといいんですが。 > これは何とかなるでしょう。 これは私の思い違いでした。 Ajaxの機能をどこまで活用するかによって エレメントに落とせるかどうか決まってきます。 極端な例を出せば UI を HTML + Javascript だけで構築することも 可能ですから、この場合TapKitのようなレイヤーがサーバーサイドに 求められます。こうなると、CGIKitはなくても良い訳で、 エレメントに落とすも何もなくなってしまいます。 これは極端だとしてもどこまでサーバー側でUIを構築するかという 線引きを決めないとAjaxの活用は難しいです。 __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From suzuki ＠ spice-of-life.net Sun Apr 24 18:22:28 2005 From: suzuki ＠ spice-of-life.net (SUZUKI Tetsuya) Date: Sun, 24 Apr 2005 18:22:28 +0900 Subject: [cgikit-dev 9] Re: Document In-Reply-To: <20050424045303.73651.qmail@web2707.mail.mci.yahoo.co.jp> References: <20050424045303.73651.qmail@web2707.mail.mci.yahoo.co.jp> Message-ID: <47abfff9ead4bbb856ecdadd36ad0bee@spice-of-life.net> 鈴木です。 On 2005/04/24, at 13:53, speakillof wrote: >>> 私はメソッドにカテゴリを設定してみたいです。 >>> Rubyは言語仕様としてのカテゴリはサポートしていませんが、 >>> 単にメソッドがアルファベット順に並ぶより見やすいと思います。 >>> CGIKit::Componentを例にすると、次のようなイメージです。 ... > 1ページにつきメソッドの説明が1つという形でなくても良いですね。 > categoryの指定方法さえ決まれば処理できると思います。 こんな感じです。ただページを作るするだけなら見出しで十分なんですが。 http://www.realintegrity.net/~squeak/pukiwiki/pukiwiki.php?String http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ ObjC_classic/Classes/NSString.html#//apple_ref/doc/uid/20000154/10869 >>> なんとかAjaxをエレメントに落とせるといいんですが。 >> これは何とかなるでしょう。 > これは私の思い違いでした。 > Ajaxの機能をどこまで活用するかによって > エレメントに落とせるかどうか決まってきます。 ... > これは極端だとしてもどこまでサーバー側でUIを構築するかという > 線引きを決めないとAjaxの活用は難しいです。 CGIKitでできるのは、ごく簡単なAjaxのスクリプトを出力するくらいですか。 でもそれだとエレメントにしてもたいして役に立たないかもしれません。 > とりあえず私のほうでプロトタイプを作ってみます。 よろしくお願いします。 ----------------------------------- 鈴木鉄也 (SUZUKI Tetsuya) suzuki ＠ spice-of-life.net http://www.spice-of-life.net/ From suzuki ＠ spice-of-life.net Sun Apr 24 19:21:02 2005 From: suzuki ＠ spice-of-life.net (SUZUKI Tetsuya) Date: Sun, 24 Apr 2005 19:21:02 +0900 Subject: [cgikit-dev 10] =?iso-2022-jp?b?UmU6IENHSUtpdCAbJEIkTiVqJWobKEI=?= =?iso-2022-jp?b?GyRCITwlOSRLJEQkJCRGGyhC?= In-Reply-To: <20050423145335.26396.qmail@web2701.mail.mci.yahoo.co.jp> References: <20050423145335.26396.qmail@web2701.mail.mci.yahoo.co.jp> Message-ID: 鈴木です。 On 2005/04/23, at 23:53, speakillof wrote: >> RHGの前にプレビューリリースを一度しておこうと思いますが、 >> WEBrickのmultipartは未サポートにしておきましょうか？ > 大きなファイルは扱えませんと明示しておけば良いと思います。 > multipartをまったく扱えないわけではありませんから。 了解しました。 >> Hashの場合のみkey, value属性を持つHashRepetitionにして、 >> 通常のRepetitionでは任意の数のitem属性を使えるようにしたらどうでしょう。 ... >> など、３つのitem属性を使うようにします。 > item1,2,3,4,5,6．．．となるわけですよね? > 属性の名前がちょっと．．．。 > これを実装する場合はHashRepetitionも > Repetitionに含めてOKだと思いますが。 まだ実装はしませんが、Repetitionの仕様は変更する可能性があると書いておきます。 Repetitionが任意の数のeachブロック引数を扱えるようにする場合、 HashRepetitionは用意しません。 任意の数のitem属性の代わりに、item属性に配列で引数リストを指定する方法も考えてみました。 each {|a, b| ...} のとき、次のように指定するとブロック引数が@a, @bに代入されます。 :element => Repetition, :list => :list, :item => [:a, :b] >> ドラッグ＆ドロップでコンポーネントを編集できなければ、 >> エディタで直接編集するのと大差ないような気がします。 > このあたりはwxWindowsも同じかもしれません。 > でも、DnDした時に再ロードをかければ編集したように見せかけることが > できると思います。 すみません、ドラッグ＆ドロップの意味がうまく伝えられませんでした。 こちらに15分でWebObjectsアプリを作るデモがあります。 4:30あたりからコンポーネントを編集しているので、見てみてください。 http://rentzsch.com/share/wo5in15.mov >>> # DirectAction用のフレームワークも考えたいですね。 >> これ、CGIKit 1.xのときの方法が役に立つのではないかと考えています。 >> 扱うデータを文字列、数値などに限定すれば、DirectAction時でも（ある程度）自動的なフォーム処理を行えると思います。 > # 1.xの記憶があまり残っていないのですが．．．。 やっていることは基本的に同じです。name属性にエレメントIDを設定し、 フォームデータを変数に代入します。 セッションを使わないフォームエレメントを別に用意することになると思います。 # ただ、この1.xの方法では拡張するのが大変だから2.xの構成に変更したわけで、 # あまり凝ったことはできません。 > 私は ダイレクトアクションに引数をつけることを考えていました。 > > セッション(や認証)が必要無いという前提ですが、 > Linkエレメント等にアクションの引数を設定します。 > リンクの生成時にGETリクエストにPStore + escapse したデータ > を貼り付けてダイレクトアクションの実行直前に引数を復元して > 引数付きで実行するという形です。 面白そうですが、２点気になります。 * URIの長さ制限 Marshalしたデータが大きい場合、Webサーバによって処理できない可能性があります。 * セキュリティ DirectActionのメソッドに引数をつけられるようにすると、 任意のオブジェクトを送り付けることができるようになります。 ----------------------------------- 鈴木鉄也 (SUZUKI Tetsuya) suzuki ＠ spice-of-life.net http://www.spice-of-life.net/ From speakillof ＠ yahoo.co.jp Sun Apr 24 20:59:16 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Sun, 24 Apr 2005 20:59:16 +0900 (JST) Subject: [cgikit-dev 11] =?iso-2022-jp?b?UmU6IENHSUtpdCAbJEIkTiVqJWobKEI=?= =?iso-2022-jp?b?GyRCITwlOSRLJEQkJCRGGyhC?= In-Reply-To: Message-ID: <20050424115916.81866.qmail@web2706.mail.mci.yahoo.co.jp> > 任意の数のitem属性の代わりに、item属性に配列で引数リストを指定する方 法も考えてみました。 > each {|a, b| ...} のとき、次のように指定するとブロック引数が@a, > @bに代入されます。 > > :element => Repetition, > :list => :list, > :item => [:a, :b] こちらの方がいいかもしれません。 Rubyで別文法を作っている気がしますが、 すっきりしていると思います。 > すみません、ドラッグ＆ドロップの意味がうまく伝えられませんでした。 > こちらに15分でWebObjectsアプリを作るデモがあります。 これからダウンロードしてみます。 ナローバンドなので、時間がかかります(苦笑) > >>> # DirectAction用のフレームワークも考えたいですね。 > > # 1.xの記憶があまり残っていないのですが．．．。 > > やっていることは基本的に同じです。name属性にエレメントIDを設定し、 > フォームデータを変数に代入します。 > セッションを使わないフォームエレメントを別に用意することになると思い ます。 うーん。同じような機能のエレメントはあまり増やしたくないですね。 > > 私は ダイレクトアクションに引数をつけることを考えていました。 > 面白そうですが、２点気になります。 > > * URIの長さ制限 > * セキュリティ やはり同じ事を思いつきますね。 後者は大丈夫のような気もするんですが、やっぱり危険かな。 引数付きダイレクトアクションを可能にする場合、 落としどころはWebObjectsの queryDictionary かなと思います。 http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_5.1/Reference/DynamicElements/WOActionURL/WOActionURL.html # 結局、WOに戻っていきますねー。 __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From speakillof ＠ yahoo.co.jp Sun Apr 24 22:35:18 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Sun, 24 Apr 2005 22:35:18 +0900 (JST) Subject: [cgikit-dev 12] REXML::Encoding Message-ID: <20050424133518.70363.qmail@web2703.mail.mci.yahoo.co.jp> REXML::Encodingに対してメソッド再定義を行うパッチです。 簡単なテストだけ行っています。 古いREXMLの仕様を確認したところ、 デフォルトでメソッド再定義を行うのは危険と判断しました。 そのためRuby-1.8.2以下ではエラーが生じるようにしています。 今のところ、普及しているRuby-1.8.2以下で強制的に エラーを出すのは好ましくないでしょうから、 Ruby-1.8.3移行でもメソッドの再定義はデフォルトでOFFです。 ONにしたい場合は CGIKit::Application.precede_iconv を false にします。 # クラス変数にしたのは一回requireすると元に戻すのが大変だからです。 これでよければこちらでコミットしますが、どうでしょう? # 仮にコミットするとなった場合、ja.rbとencoding-patch.rbを # langディレクトリの下に押し込みたいのですが、よろしいですか? --- C:\Documents and Settings\Administrator\Local Settings\Temp\TCV543d.tmp\parser.1.66.rb Fri Apr 15 08:09:44 2005 +++ D:\cgikit\lib\cgikit\parser.rb Sun Apr 24 21:52:26 2005 @@ -1,5 +1,7 @@ if $0 == __FILE__ + $:.unshift('./') require 'cgikit' + require 'cgikit/ja' end module CGIKit::HTMLParser @@ -350,6 +352,9 @@ unless Object.const_defined?('REXML') require 'rexml/document' require 'rexml/streamlistener' + unless CGIKit::Application.precede_iconv + require 'cgikit/lang/encoding-patch.rb' + end end @declarations = {} --- C:\Documents and Settings\Administrator\Local Settings\Temp\TCVaac2.tmp\ja.1.2.rb Mon Mar 21 18:34:46 2005 +++ D:\cgikit\lib\cgikit\ja.rb Sun Apr 24 21:24:20 2005 @@ -2,7 +2,14 @@ require 'kconv' module CGIKit - + +class Application + class << self + attr_accessor :precede_iconv + end + self.precede_iconv = true +end + class DynamicElement def encode_string( string, encoding ) Kconv.kconv(string, encoding) __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: encoding-patch.rb 型: application/octet-stream サイズ: 1445 バイト 説明: encoding-patch.rb URL: http://lists.sourceforge.jp/mailman/archives/cgikit-dev/attachments/20050424/84d4b679/attachment.obj From suzuki ＠ spice-of-life.net Sun Apr 24 22:45:25 2005 From: suzuki ＠ spice-of-life.net (SUZUKI Tetsuya) Date: Sun, 24 Apr 2005 22:45:25 +0900 Subject: [cgikit-dev 13] =?iso-2022-jp?b?UmU6IENHSUtpdCAbJEIkTiVqJWobKEI=?= =?iso-2022-jp?b?GyRCITwlOSRLJEQkJCRGGyhC?= In-Reply-To: <20050424115916.81866.qmail@web2706.mail.mci.yahoo.co.jp> References: <20050424115916.81866.qmail@web2706.mail.mci.yahoo.co.jp> Message-ID: <2400a742acbcc5ec385825d0e417b40f@spice-of-life.net> 鈴木です。 On 2005/04/24, at 20:59, speakillof wrote: >>> 私は ダイレクトアクションに引数をつけることを考えていました。 >> 面白そうですが、２点気になります。 >> * URIの長さ制限 >> * セキュリティ > やはり同じ事を思いつきますね。 > 後者は大丈夫のような気もするんですが、やっぱり危険かな。 アクションメソッドの実装にもよると思いますが、 クエリに文字列のみを埋め込むよりも攻撃される幅は広がると思います。 > 引数付きダイレクトアクションを可能にする場合、 > 落としどころはWebObjectsの queryDictionary かなと思います。 queryDictionaryはCGIKitのLinkのqueryと同じです。 ?keyはCGIKitでは未実装です。 # こちらが最新版です。 # http://developer.apple.com/documentation/WebObjects/Reference/ DynamicElements/index.html > # 結局、WOに戻っていきますねー。 やはり似たようなことを考えてきたんでしょうね。 ----------------------------------- 鈴木鉄也 (SUZUKI Tetsuya) suzuki ＠ spice-of-life.net http://www.spice-of-life.net/ From suzuki ＠ spice-of-life.net Mon Apr 25 21:59:27 2005 From: suzuki ＠ spice-of-life.net (SUZUKI Tetsuya) Date: Mon, 25 Apr 2005 21:59:27 +0900 Subject: [cgikit-dev 14] Re: REXML::Encoding In-Reply-To: <20050424133518.70363.qmail@web2703.mail.mci.yahoo.co.jp> References: <20050424133518.70363.qmail@web2703.mail.mci.yahoo.co.jp> Message-ID: <00ac4a5d9bba1e2069193f2dc43b04a8@spice-of-life.net> 鈴木です。 On 2005/04/24, at 22:35, speakillof wrote: > REXML::Encodingに対してメソッド再定義を行うパッチです。 > 簡単なテストだけ行っています。 ... > これでよければこちらでコミットしますが、どうでしょう? > > # 仮にコミットするとなった場合、ja.rbとencoding-patch.rbを > # langディレクトリの下に押し込みたいのですが、よろしいですか? 了解しました。よろしくお願いします。 ----------------------------------- 鈴木鉄也 (SUZUKI Tetsuya) suzuki ＠ spice-of-life.net http://www.spice-of-life.net/ From speakillof ＠ yahoo.co.jp Tue Apr 26 07:59:11 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Tue, 26 Apr 2005 07:59:11 +0900 (JST) Subject: [cgikit-dev 15] Re: REXML::Encoding In-Reply-To: <00ac4a5d9bba1e2069193f2dc43b04a8@spice-of-life.net> Message-ID: <20050425225911.33665.qmail@web2701.mail.mci.yahoo.co.jp> > > REXML::Encodingに対してメソッド再定義を行うパッチです。 > > 簡単なテストだけ行っています。 > ... > > これでよければこちらでコミットしますが、どうでしょう? > 了解しました。よろしくお願いします。 commitしました。 最終的に設定名を CGIKit::Application.precede_iconv_as_rexml_encoding_module としました。precede_iconvだとどこでiconvが優先されるのか 分かりにくいですから。 それと各種サンプルとライブラリーでcgikit/jaになっていたのを cgikit/lang/jaにしています。 __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From speakillof ＠ yahoo.co.jp Thu Apr 28 20:06:45 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Thu, 28 Apr 2005 20:06:45 +0900 (JST) Subject: [cgikit-dev 16] ByteData Message-ID: <20050428110645.66804.qmail@web2706.mail.mci.yahoo.co.jp> こちらに移ります。 > > ByteData > > > > それと、最後に質問ですけど、tempfileがcloseされる保証ってあります? > あ、今の実装ではありませんでした。 > これはどうしましょうか。WEBrickだと明示的にcloseしないと > tempfileが開きっぱなしになってしまいますね。 > 各メソッドで逐一open-closeするのもメモリの無駄遣いですし。 > Upload#invoke_actionで使用されたByteDataをcloseすれば確実ですが、 > これは影響を及ぼす範囲が広そうです。 いくつか方法があると思います。 * ObjectSpace.define_finalizer を使って、ByteDataがGCで開放される時にtempfile をcloseする。 * awake, take_value, invoke_action, append に続いてWOのsleep(?) 相当を 定義して、ここでクローズする * 鈴木さんが言われるようにByteDataには一時ファイルのファイル名のみを保 持する。 1つ目は個人的に少し気持ち悪いです。 2つ目はCGIKit側に大きな変更が必要? 3つ目が一番良いと思います。確かにopen/closeが必要ですが、 ByteDataに保持したまま操作をしないようにユーザーに促せば良いでしょう。 3つ目の方法の問題は一時ファイルを実際に消す方法です。 Tempfile任せにすると、 http://www.ruby-lang.org/ja/man/?cmd=view;name=Tempfile 結局はGC任せになるみたいですね。 1つめと同じになるのかなあ? __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From suzuki ＠ spice-of-life.net Thu Apr 28 20:59:05 2005 From: suzuki ＠ spice-of-life.net (SUZUKI Tetsuya) Date: Thu, 28 Apr 2005 20:59:05 +0900 Subject: [cgikit-dev 17] Re: ByteData In-Reply-To: <20050428110645.66804.qmail@web2706.mail.mci.yahoo.co.jp> References: <20050428110645.66804.qmail@web2706.mail.mci.yahoo.co.jp> Message-ID: <7bd9adcf23b266e4b78e86922a0da8ef@spice-of-life.net> 鈴木です。 On 2005/04/28, at 20:06, speakillof wrote: > * ObjectSpace.define_finalizer > を使って、ByteDataがGCで開放される時にtempfile > をcloseする。 > * awake, take_value, invoke_action, append に続いてWOのsleep(?) 相当を > 定義して、ここでクローズする > * 鈴木さんが言われるようにByteDataには一時ファイルのファイル名のみを保 > 持する。 1, 2も考えたのですが、ByteDataの使い方がややこしくなりそうでしたので、 結局、各メソッドでopen-closeするように実装し直しました。 ただ、一時ファイルを消すのはGC任せになっています。 ----------------------------------- 鈴木鉄也 (SUZUKI Tetsuya) suzuki ＠ spice-of-life.net http://www.spice-of-life.net/