From suzuki ＠ spice-of-life.net Sat May 7 16:21:30 2005 From: suzuki ＠ spice-of-life.net (SUZUKI Tetsuya) Date: Sat, 7 May 2005 16:21:30 +0900 Subject: [cgikit-dev 18] [ANN] CGIKit 2.0.0 preview 1 Message-ID: 鈴木です。 CGIKit 2.0.0 preview 1 をリリースしました。 1.xから大幅に仕様が変わっています。変更点はWikiを参照して ください。 * ダウンロード https://sourceforge.jp/projects/cgikit/files/ * Wiki http://cgikit.sourceforge.jp/cgi-bin/ja/index.cgi なお今回のリリースにあたり、speakillofさんには パーザの実装やドキュメントなど幅広く手伝っていただきました。 どうもありがとうございました。 ----------------------------------- 鈴木鉄也 (SUZUKI Tetsuya) suzuki ＠ spice-of-life.net http://www.spice-of-life.net/ From speakillof ＠ yahoo.co.jp Sun May 15 23:45:38 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Sun, 15 May 2005 23:45:38 +0900 (JST) Subject: [cgikit-dev 19] =?iso-2022-jp?b?Q0dJS2l0IBskQkBsTVEkTiVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJVYlaSVqGyhC?= Message-ID: <20050515144538.95922.qmail@web2708.mail.mci.yahoo.co.jp> 日記へのコメントですが、こちらで行います。 CKWiki/ lib/... ライブラリ + コンポーネント (.rb) components/... コンポーネント (.html + .ckd) resources/... リソース www/... Webサーバリソース これはプロジェクトのトップディレクトリが CKWikiということですよね？ この前提の場合、別のところで開発されたコンポーネントを どうやってCKWikiプロジェクトにインストールするかということが問題です。 提案ですが、RubyGems + セットアップスクリプトを使いませんか？ http://rubygems.rubyforge.org/wiki/wiki.pl?action=edit&id=HomePage http://www.programmers-paradise.com/ruby/rubygems.html http://onestepback.org/articles/rubygemsfacets/index.html RubyGemsならディレクトリ構成は好きにできます。 (package_top_dir) | +-- hoge | +-- foo という構成でも設定ファイルさえ書けば きちんとパッケージングしてくれます。 CKWiki/ lib/... ライブラリ + コンポーネント (.rb) components/... コンポーネント (.html + .ckd) resources/... リソース www/... という構成の時にgemを作ってckwiki-0.0.0.gem を生成します。 (後でcgikti自体のgemの生成スクリプトを載せます。) プロジェクトのトップディレクトリにgemsというディレクトリを作って、 プロジェクトのトップディレクトリで gem install -i (project_top_dir)/gems ckwiki-0.0.0.gem とします。この時、iオプションをつけないと困った事になるので、 注意が必要です。これで gems 以下にファイルがinstallされます。 (project_top_dir)/gems/gems/ckwiki-0.0.0 | +-- lib | +-- components | +-- www | +-- resources この後、CGIKit専用のセットアップスクリプトを走らせて (project_top_dir)/gems/gems/ckwiki-0.0.0 にある lib, components, www, resources を プロジェクトの各ディレクトリにコピーします。 (手動コピーでも良いです) gemのプロジェクトのインストールから プロジェクトのコピーまでをセットアップスクリプトで 行う方法が一番かな？ 次にCGIKit自体のgemの生成方法です。 コンポーネントも同じ方法でパッケージングします。 require 'rubygems' spec = Gem::Specification.new do |s| s.name = 'cgikit' s.version = '2.0.0.20050515' s.summary = 'Web Application Framework with pure-XHTML Template and auto Session-Management' s.description = %Q|CGIKit is a Web Application framework based on components.| s.files = Dir['lib/**/*.rb'] + Dir['test/**/*'] + Dir['misc/**/*'] + Dir['examples/**/*'] s.files = s.files.reject{|i| (/^CVS/ =~ i) or (/\~\z/) =~ i } s.require_path = 'lib' s.autorequire = 'cgikit' s.has_rdoc = true # false s.author = 'Testuya Suzuki' s.email = 'suzuki ＠ spice-of-life.net' s.homepage = 'http://cgikit.sourceforge.net/' s.required_ruby_version = '>= 1.8.2' end というファイル(gem.specとします)をCGIKitのトップディレクトリに置き、 gem build gem.spec で生成できます。(簡単？) この方法の長所は * setup.rb のディレクトリ構成のしばりがない * バージョン管理も可能(ちょっと難しいですが) 短所は * セットアップスクリプトが必要。 * プロジェクトにインストールしたコンポンーネントを削除する方法がない。 でしょうか。 __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From speakillof ＠ yahoo.co.jp Sun May 15 23:55:51 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Sun, 15 May 2005 23:55:51 +0900 (JST) Subject: [cgikit-dev 20] =?iso-2022-jp?b?UmU6IENHSUtpdCAbJEJAbE1RJE4bKEI=?= =?iso-2022-jp?b?GyRCJWklJCVWJWklahsoQg==?= In-Reply-To: <20050515144538.95922.qmail@web2708.mail.mci.yahoo.co.jp> Message-ID: <20050515145551.1483.qmail@web2702.mail.mci.yahoo.co.jp> さっきのメールは分かりにくいですね。すいません。 gem生成の部分からはCKWikiコンポーネントを自分用のプロジェクトに どうインストールさせるかという記述になっています。 別の例を出すべきでした。 例えば、 CKHoge というプロジェクトがあるとします。 CKHoge gems www resources lib components ここに CKFoo というコンポーネントをインストールしたいとします。 CKFoo www resouces lib components この時、ckfoo-0.0.0.gemを生成して gem install -i ckhoge/gems ckfoo-0.0.0.gem でインストールします。 ckhoge/ gems/ gems/ ckfoo-0.0.0/ www/ resouces/ lib/ components/ これで上記のような構成になります。この後、 ckhoge/gems/gems/ckfoo-0.0.0/* を ckhoge に何らかの方法で コピーします。これでCKHogeというプロジェクトに CKFooがインストールされたことになります。 __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From suzuki ＠ spice-of-life.net Mon May 16 03:42:17 2005 From: suzuki ＠ spice-of-life.net (SUZUKI Tetsuya) Date: Mon, 16 May 2005 03:42:17 +0900 Subject: [cgikit-dev 21] =?iso-2022-jp?b?UmU6IENHSUtpdCAbJEJAbE1RJE4bKEI=?= =?iso-2022-jp?b?GyRCJWklJCVWJWklahsoQg==?= In-Reply-To: <20050515144538.95922.qmail@web2708.mail.mci.yahoo.co.jp> References: <20050515144538.95922.qmail@web2708.mail.mci.yahoo.co.jp> Message-ID: 鈴木です。 On 2005/05/15, at 23:45, speakillof wrote: > 提案ですが、RubyGems + セットアップスクリプトを使いませ > んか？ なるほど、RubyGemsを使うならセットアップスクリプトを書けば CGIKit専用ライブラリもわりと簡単にできそうですね。 全然気づきませんでした。 > 短所は > > * セットアップスクリプトが必要。 > * プロジェクトにインストールしたコンポンーネントを削除する方法 > がない。 > > でしょうか。 もうひとつ、gemを使わない場合のインストールが大変です。 CGIKit本体だけならlib/以下をまるごとコピーするだけで済みま すが、 gemが前提となるとCGIでは厳しくなると思います。 gemより手間はかかりますが、WebObjects風パッケージだとこの 点楽になりそうです。 もう少し考えてみました。 例えば、CKWikiが次のような構成になっているとします。 CKWiki/ lib/ components/ resources/ www/ これに、別に開発されたコンポーネント群 Foo をインストール するとします。 Fooのディレクトリ構成も似たようなものになっています。 Foo/ lib/ components/ resources/ www/ CKWiki以下に package ディレクトリを作り、Fooをディレ クトリごとコピーします。 CKWiki/ lib/ components/ resources/ www/ package/ Foo/ ... あとは、CKWikiのライブラリのどこかでFooパッケージを ロードします。 package 'Foo' package はパッケージを読み込む関数とします。 これでFooのlib以下がロードパスに追加され、 componentsやresourcesも CGIKitの各パスに追加され、Fooパッケージの内容を扱えるよう になります。 長所は * setup.rb のディレクトリ構成のしばりがない * インストールが簡単 短所は * パッケージシステムを実装する必要がある * パッケージのルールに従う必要がある * CGIKitも一部実装し直す必要がある (リソースのパスが複数にできない、など) です。 # 「パッケージ」という言葉は誤解を招きそうですね。 # WebObjectsと同じですが、「バンドル」がいいかも。 ----------------------------------- 鈴木鉄也 (SUZUKI Tetsuya) suzuki ＠ spice-of-life.net http://www.spice-of-life.net/ From speakillof ＠ yahoo.co.jp Mon May 16 18:49:47 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Mon, 16 May 2005 18:49:47 +0900 (JST) Subject: [cgikit-dev 22] =?iso-2022-jp?b?UmU6IENHSUtpdCAbJEJAbE1RJE4bKEI=?= =?iso-2022-jp?b?GyRCJWklJCVWJWklahsoQg==?= In-Reply-To: Message-ID: <20050516094947.82455.qmail@web2708.mail.mci.yahoo.co.jp> > > 提案ですが、RubyGems + セットアップスクリプトを使いませんか？ > > > 短所は > > > > * セットアップスクリプトが必要。 > > * プロジェクトにインストールしたコンポンーネントを削除する方法 > > がない。 これはgems以下にもとのファイルが残っていれば可能ですね。 > もうひとつ、gemを使わない場合のインストールが大変です。 > CGIKit本体だけならlib/以下をまるごとコピーするだけで済みますが、 > gemが前提となるとCGIでは厳しくなると思います。 開発者はまずローカルな環境でテストしますよね？ この時にパッケージをインストールする際にはgemを使います。 で、プロジェクトが進んだら、そのプロジェクトの トップディレクトリをCGI実行用のサーバーにコピーします。 この時にgemは要りません。 作ったCGIを配布する時もプロジェクトの トップディレクトリをzipなり、tarなりで固めるだけです。 CGIのみで使う場合でも、いったん必要なパッケージをローカルに作った プロジェクト用のディレクトリに保存してからアップすれば良いですよね。 > gemより手間はかかりますが、WebObjects風パッケージだとこの > 点楽になりそうです。 > > 例えば、CKWikiが次のような構成になっているとします。 > > CKWiki/ > lib/ > components/ > resources/ > www/ > > これに、別に開発されたコンポーネント群 Foo をインストール > するとします。 > Fooのディレクトリ構成も似たようなものになっています。 > > Foo/ > lib/ > components/ > resources/ > www/ > > CKWiki以下に package ディレクトリを作り、Fooをディレ > クトリごとコピーします。 > > CKWiki/ > lib/ > components/ > resources/ > www/ > package/ > Foo/ > ... > > あとは、CKWikiのライブラリのどこかでFooパッケージを > ロードします。 > > package 'Foo' > > package はパッケージを読み込む関数とします。 > これでFooのlib以下がロードパスに追加され、 > componentsやresourcesも > CGIKitの各パスに追加され、Fooパッケージの内容を扱えるよう > になります。 私の提案した方法だと、何らかの方法でリソースの名前の衝突を 避けないといけません。 (パッケージに含まれるリソースの名前が一致すると コピーの際に上書きされてしまいます) この方法だとインストールの際のリソースの上書きは 避けることが出来ますね。 > 長所は > > * setup.rb のディレクトリ構成のしばりがない > * インストールが簡単 > > 短所は > > * パッケージシステムを実装する必要がある > * パッケージのルールに従う必要がある パッケージシステムを作るのはいいのですが、 > * CGIKitも一部実装し直す必要がある > (リソースのパスが複数にできない、など) リソース・コンポーネントの探索を複数パスに設定可能にすると 遅くならないでしょうか．．．。(今でも遅いので、誤差範囲かな？) もう1点気になることはリソース名の解決です。 Foo, Barのリソースとして両者とも www/hoge.png を持っているとします。 CKWiki/ lib/ components/ resources/ www/ package/ Foo/ www/hoge.png ... Bar www/hoge.png ... 両者をインストールすると、上のようになります。 今のCGIKitの実装だと、Fooからリソース名を解決しようが、 Barからリソース名を解決しようが、 同じリソース名になってしまいます。 Fooからリソース名の解決では CKWiki/package/Foo/www/hoge.png でなくてはなりませんし、 Barからリソース名の解決では CKWiki/package/Foo/www/hoge.png でなくてはなりません。 これが解決できないと、この方法は難しいです。 # Bindingオブジェクトを使えば回避できるかな？ __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From suzuki ＠ spice-of-life.net Tue May 17 00:28:33 2005 From: suzuki ＠ spice-of-life.net (SUZUKI Tetsuya) Date: Tue, 17 May 2005 00:28:33 +0900 Subject: [cgikit-dev 23] =?iso-2022-jp?b?UmU6IENHSUtpdCAbJEJAbE1RJE4bKEI=?= =?iso-2022-jp?b?GyRCJWklJCVWJWklahsoQg==?= In-Reply-To: <20050516094947.82455.qmail@web2708.mail.mci.yahoo.co.jp> References: <20050516094947.82455.qmail@web2708.mail.mci.yahoo.co.jp> Message-ID: 鈴木です。 On 2005/05/16, at 18:49, speakillof wrote: >> もうひとつ、gemを使わない場合のインストールが大変です。 >> CGIKit本体だけならlib/以下をまるごとコピーするだけで済 >> みますが、 >> gemが前提となるとCGIでは厳しくなると思います。 > 開発者はまずローカルな環境でテストしますよね？ > この時にパッケージをインストールする際にはgemを使います。 ... > CGIのみで使う場合でも、いったん必要なパッケージをローカルに > 作った > プロジェクト用のディレクトリに保存してからアップすれば良いです > よね。 ああ、なるほど、ローカルで準備してからアップすればいいんですね。 パッケージシステムにする場合でも、gemが役立つと思います。 CGIKitアプリケーションで共有するパッケージをインストールする場合、 (/usr/local/share以下など) setup.rbよりgemのほうが便利そうです。 RubyGems + セットアップスクリプト + パッケージシステムを 組み合わせるのがよさそうです。 >> * CGIKitも一部実装し直す必要がある >> (リソースのパスが複数にできない、など) > リソース・コンポーネントの探索を複数パスに設定可能にすると > 遅くならないでしょうか．．．。(今でも遅いので、誤差範囲 > かな？) > > もう1点気になることはリソース名の解決です。 ResourceManagerからリソースを取得する際に パッケージも指定するようにすれば、リソース名は競合しません。 Imageエレメントにもpackgae属性を追加して、 リソース名とパッケージ名を指定してもらうことにします。 こうすればリソースの探索は複数パスにならなくてすむと思います。 ----------------------------------- 鈴木鉄也 (SUZUKI Tetsuya) suzuki ＠ spice-of-life.net http://www.spice-of-life.net/ From speakillof ＠ yahoo.co.jp Tue May 17 20:07:02 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Tue, 17 May 2005 20:07:02 +0900 (JST) Subject: [cgikit-dev 24] =?iso-2022-jp?b?UmU6IENHSUtpdCAbJEJAbE1RJE4bKEI=?= =?iso-2022-jp?b?GyRCJWklJCVWJWklahsoQg==?= In-Reply-To: Message-ID: <20050517110702.32789.qmail@web2707.mail.mci.yahoo.co.jp> > > もう1点気になることはリソース名の解決です。 > > ResourceManagerからリソースを取得する際に > パッケージも指定するようにすれば、リソース名は競合しません。 > Imageエレメントにもpackgae属性を追加して、 > リソース名とパッケージ名を指定してもらうことにします。 > こうすればリソースの探索は複数パスにならなくてすむと思います。 となると、リソース名探索に関わるメソッドは すべて引数が増えるわけですね。 私としては増えた引数は省略可能にして欲しいです。 * 省略時 globalなディレクトリから探索 つまりCGIKit::Applicationに指定されている web_server_resoucrcesなどから * 指定時 各パッケージから探索 ところで、各パッケージからの探索のディレクトリ指定はどうします？ 例えば CKWiki package FooComponent www hoge.png public_html hoge.jpg foobar.css となっているとします。 Fooコンポーネントで resouce_manager.url('hoge.png', 'Foo') とした時、CKWiki/package/FooComponent/wwwから探索して欲しいわけですが、 CGIKit::Applicationには CKWiki/public_html が指定されています。 CKWiki/package/FooComponent/www を探索してもらうには * FooComponent#web_server_resouce というメソッドを定義 * パッケージのWebサーバーリソースをwwwに固定 のいずれかの方法が考えられますが、他に良い方法はありますか？ __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From suzuki ＠ spice-of-life.net Wed May 18 15:38:06 2005 From: suzuki ＠ spice-of-life.net (SUZUKI Tetsuya) Date: Wed, 18 May 2005 15:38:06 +0900 Subject: [cgikit-dev 25] =?iso-2022-jp?b?UmU6IENHSUtpdCAbJEJAbE1RJE4bKEI=?= =?iso-2022-jp?b?GyRCJWklJCVWJWklahsoQg==?= In-Reply-To: <20050517110702.32789.qmail@web2707.mail.mci.yahoo.co.jp> References: <20050517110702.32789.qmail@web2707.mail.mci.yahoo.co.jp> Message-ID: 鈴木です。 On 2005/05/17, at 20:07, speakillof wrote: > となると、リソース名探索に関わるメソッドは > すべて引数が増えるわけですね。 > > 私としては増えた引数は省略可能にして欲しいです。 > > * 省略時 > globalなディレクトリから探索 > つまりCGIKit::Applicationに指定されている > web_server_resoucrcesなどから 省略した場合、CGIKit::Applicationの設定から探す予定です。 アプリケーション自体も一つのパッケージとして扱います。 > ところで、各パッケージからの探索のディレクトリ指定はどうします？ ... > CKWiki/package/FooComponent/www を探索してもらうには > > * FooComponent#web_server_resouce というメソッドを定義 > * パッケージのWebサーバーリソースをwwwに固定 > > のいずれかの方法が考えられますが、他に良い方法はありますか？ 基本的には後者の www に固定の方法をとりたいと思います。 ただし、Webサーバリソースだけドキュメントルートからも検索 します。 パッケージを DATADIR/cgikit/packages にインストールできる とすると、 ドキュメントルートにも同様に DOCROOT/cgikit/packages を用 意します。 そこにWebサーバリソースだけ置くことにします。 例えばCKWikiにFooがインストールされ、 web_server_resources が /var/www/htdocs に指定されていると します。 CKWiki packages Foo www hoge.png Fooパッケージのリソースを次のように取得するとき、 resouce_manager.url('hoge.png', 'Foo') 次のディレクトリから hoge.png が検索されます。 * /var/www/htdocs/cgikit/packages/Foo/www/ * CKWiki/packages/Foo/www * /usr/share/cgikit/packages/Foo/www/ ----------------------------------- 鈴木鉄也 (SUZUKI Tetsuya) suzuki ＠ spice-of-life.net http://www.spice-of-life.net/ From speakillof ＠ yahoo.co.jp Thu May 19 07:05:30 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Thu, 19 May 2005 07:05:30 +0900 (JST) Subject: [cgikit-dev 26] =?iso-2022-jp?b?UmU6IENHSUtpdCAbJEJAbE1RJE4bKEI=?= =?iso-2022-jp?b?GyRCJWklJCVWJWklahsoQg==?= In-Reply-To: Message-ID: <20050518220531.61167.qmail@web2705.mail.mci.yahoo.co.jp> > > ところで、各パッケージからの探索のディレクトリ指定はどうします？ > 例えばCKWikiにFooがインストールされ、 > web_server_resources が /var/www/htdocs に指定されていると > します。 > > CKWiki > packages > Foo > www > hoge.png > > Fooパッケージのリソースを次のように取得するとき、 > > resouce_manager.url('hoge.png', 'Foo') > > 次のディレクトリから hoge.png が検索されます。 > > * /var/www/htdocs/cgikit/packages/Foo/www/ > * CKWiki/packages/Foo/www > * /usr/share/cgikit/packages/Foo/www/ この方が良いですね。データが2重にコピーされますけど、 パーミッション周りが扱いやすくなります。 __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From speakillof ＠ yahoo.co.jp Thu May 19 07:14:44 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Thu, 19 May 2005 07:14:44 +0900 (JST) Subject: [cgikit-dev 27] =?iso-2022-jp?b?GyRCJUYlcyVXJWwhPCVIJE5KODt6GyhC?= =?iso-2022-jp?b?GyRCJTMhPCVJO1hEahsoQg==?= Message-ID: <20050518221444.4403.qmail@web2706.mail.mci.yahoo.co.jp> 今のテンプレートは の encoding を見て テンプレートの文字コードを決定しており、 サブコンポーネントのテンプレートの文字コードを指定する時にも 同じ方法を使います。 この時、今のパーサーは を問答無用で出力するので、 2重に が出力されてしまいます。 解決方法 * すべての を出力しない * CGIKitからパーサー側にルートコンポーネントであるという情報を渡す * Encoding Pragma のようなものをコメントに仕込む。 Encoding Pragmaは最近Rubyに取り込まれました。 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/4881 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/4882 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/4885 2が一番良いとは思いますが…。 __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From suzuki ＠ spice-of-life.net Fri May 20 21:07:12 2005 From: suzuki ＠ spice-of-life.net (SUZUKI Tetsuya) Date: Fri, 20 May 2005 21:07:12 +0900 Subject: [cgikit-dev 28] =?iso-2022-jp?b?UmU6IBskQiVGJXMlVyVsITwlSCROGyhC?= =?iso-2022-jp?b?GyRCSjg7eiUzITwlSTtYRGobKEI=?= In-Reply-To: <20050518221444.4403.qmail@web2706.mail.mci.yahoo.co.jp> References: <20050518221444.4403.qmail@web2706.mail.mci.yahoo.co.jp> Message-ID: <59595957-9A4A-47F2-B165-0B959CEAB559@spice-of-life.net> 鈴木です。 On 2005/05/19, at 7:14, speakillof wrote: > 今のテンプレートは の encoding を見て > テンプレートの文字コードを決定しており、 > サブコンポーネントのテンプレートの文字コードを指定する時にも > 同じ方法を使います。 > > この時、今のパーサーは を問答無用で出力する > ので、 > 2重に が出力されてしまいます。 > > > 解決方法 > > * すべての を出力しない > * CGIKitからパーサー側にルートコンポーネントであるという情報を > 渡す > * Encoding Pragma のようなものをコメントに仕込む。 2. の場合、ルートコンポーネントの のみ 表示されるということでしょうか？ サブコンポーネントとルートコンポーネントの文字コードが異なる場合 に、 表示時にルートコンポーネントの文字コードに変換するのであれば、 2. がいいと思います。 ----------------------------------- 鈴木鉄也 (SUZUKI Tetsuya) suzuki ＠ spice-of-life.net http://www.spice-of-life.net/ From speakillof ＠ yahoo.co.jp Fri May 20 23:55:31 2005 From: speakillof ＠ yahoo.co.jp (speakillof) Date: Fri, 20 May 2005 23:55:31 +0900 (JST) Subject: [cgikit-dev 29] =?iso-2022-jp?b?UmU6IBskQiVGJXMlVyVsITwlSCROGyhC?= =?iso-2022-jp?b?GyRCSjg7eiUzITwlSTtYRGobKEI=?= In-Reply-To: <59595957-9A4A-47F2-B165-0B959CEAB559@spice-of-life.net> Message-ID: <20050520145531.70648.qmail@web2705.mail.mci.yahoo.co.jp> > > 解決方法 > > > > * すべての を出力しない > > * CGIKitからパーサー側にルートコンポーネントであるという情報を > > 渡す > > * Encoding Pragma のようなものをコメントに仕込む。 > > 2. の場合、ルートコンポーネントの のみ > 表示されるということでしょうか？ そうです。 > サブコンポーネントとルートコンポーネントの > 文字コードが異なる場合に、 > 表示時にルートコンポーネントの文字コードに変換するのであれば、 > 2. がいいと思います。 ご存知のようにすべてのテンプレートは REXML::Encoding で utf-8 になってから、パースされて、その後元の文字コードに戻されます。元 の文字コードへの変換をルートコンポーネントの変換時に遅延させるか、 output, input の文字コードをパーサー内で分離するか、 のいずれかの方法で対処可能です。 問題は文字コードの変換が REXML::Encoding の枠内になるということです。 変換モジュールの妥当性を抜きにすれば utf-8を介しての shift_jis, euc-jp への変換はOKです。 # 他はやってみないと分からないですね。 # 理論上、扱える範囲はIconv(libiconv)に依存します。 __________________________________ Do You Yahoo!? Upgrade Your Life http://bb.yahoo.co.jp/ From suzuki ＠ spice-of-life.net Sat May 21 15:16:45 2005 From: suzuki ＠ spice-of-life.net (SUZUKI Tetsuya) Date: Sat, 21 May 2005 15:16:45 +0900 Subject: [cgikit-dev 30] =?iso-2022-jp?b?UmU6IBskQiVGJXMlVyVsITwlSCROGyhC?= =?iso-2022-jp?b?GyRCSjg7eiUzITwlSTtYRGobKEI=?= In-Reply-To: <20050520145531.70648.qmail@web2705.mail.mci.yahoo.co.jp> References: <20050520145531.70648.qmail@web2705.mail.mci.yahoo.co.jp> Message-ID: 鈴木です。 On 2005/05/20, at 23:55, speakillof wrote: >> サブコンポーネントとルートコンポーネントの >> 文字コードが異なる場合に、 >> 表示時にルートコンポーネントの文字コードに変換するのであれば、 >> 2. がいいと思います。 > ご存知のようにすべてのテンプレートは REXML::Encoding で > utf-8 になってから、パースされて、その後元の文字コードに戻され > ます。元 > の文字コードへの変換をルートコンポーネントの変換時に遅延させる > か、 > output, input の文字コードをパーサー内で分離するか、 > のいずれかの方法で対処可能です。 どちらの方法でも問題ないと思うので、 実装するとしたら、やりやすいほうで実装してください。 > 問題は文字コードの変換が REXML::Encoding > の枠内になるということです。 > 変換モジュールの妥当性を抜きにすれば > utf-8を介しての shift_jis, euc-jp への変換はOKです。 これはいまのところ仕方がないですね。 テンプレートの文字コードに注意してもらうしかないと思います。 ----------------------------------- 鈴木鉄也 (SUZUKI Tetsuya) suzuki ＠ spice-of-life.net http://www.spice-of-life.net/