どうもみずほです。
At Mon, 12 Aug 2002 18:28:36 +0900,
TADA Tadashi wrote:
>
> ただです。
> ># もっと言えば、この二つを別のファイルに分離して欲しいけど、ちょっと無理かな。
>
> いちおう他のIOでも使えるようにしたつもりなので、そのままincludeしても
> らっていいです。今の実装は例外処理がほとんどなんにもないので、そのあたり
> は変化すると思うけど。ファイルの分離も可能だけど……うーん、当面はこのま
> ま。
分離すると(実行速度が)遅くなるらしいので、必ずしも行う必要はないですけどね。
> いろいろ考えてみたんだけど、無理に別クラスをもうけるとあちこちに無理
> が出てきそうなので、parserキャッシュも当面はTDiaryに置きます。
それなるのであれば、それに従います。
> >個人的にはtransactionの引数と返り値を整理して欲しいです。
> >とくに引数のdiariesのデフォルト引数って必要無さそうなので、
> >無くして欲しいです。
>
> >ブロックパラメーターの有無も整理して欲しいです。
> >以前の修正でブロックパラメーターは使わないことになったと考えて良いですか?
>
> たしか以前はTDiaryLatestの周辺で必要だったんだけど、たしかに整理できな
> いこともない気がするので、近々トライしてみます。というか、IOを分離した時
> 点ですべきだったか……。
>
> ブロックパラメータありにして、transaction( date )だけにするか、逆にブ
> ロックパラメタなしにしてtransaction( date, diaries )にするかですね。後者
> がいいかな。
私は前者が好きですけど、お任せします。
> >> >8 update.rhtml
> (snip)
> >> 上で書いたとおり、@diaryのデータ構造にできるだけ依存しないようにしたい
> >> と考えてはいるので、to_textを使うようになるでしょう。to_srcみたいな名前
> >> の方が直感的かな。
> >私はto_srcの方が好きです。
>
> >update.rhtmlではto_textよりもto_srcの方が
> >望ましいので、そちらを使ってもらえると嬉しいです。
>
> じゃあ、to_srcにしましょう。
ありがとうございます。
> >ざーーとpluginを読んでみたんですが。
> >
> >一番対応が難しそうなのがcalendar3.rbとrecent_list.rbですね。
> >修正が必要なのがdisp_referrer.rbとrecent_list.rbです。
> >TDiary系のオブジェクトを実行時に生成するのは試してみないと分からないです。
> >
> ># yasqueeze.rbが動くとうれしんだけど、どうかなあ？
>
> yasqueezeをはじめ、TDiaryXxx系のクラスを書き換えてるプラグインは全滅の
> 可能性は覚悟の上だと思うので、まぁいいかと(笑)。このあたりはAPIを整備し
> たいと思ってはいるんですけどね……ちょっとまだ余裕がない。
現在のtdiary-hnfで試してみましたが、calendar3.rb、makelirs.rbはそのままでも動きます。
# calendar3.rbは挙動がおかしいですけど。
yasqueeze.rbも動きますが、プラグイン側に修正が必要です。
この修正をしないと、デフォルトの設定でも1.5系では動かないと思います。
--- yasqueeze.rb.org Mon Aug 12 04:50:26 2002
+++ yasqueeze.rb Mon Aug 12 04:43:42 2002
@@ -224,10 +224,11 @@
class YATDiarySqueezeMain < TDiary
def initialize(dest, all_data, compat)
super(nil, 'day.rhtml')
- make_years
+ #make_years
+ calendar
@years.keys.sort.each do |year|
@years[year.to_s].sort.each do |month|
- transaction(Time::local(year.to_i, month.to_i)) do |diaries|
+ @io.transaction(Time::local(year.to_i, month.to_i)) do |diaries|
diaries.sort.each do |day, diary|
> あぁ、そうでしたか。なんかうやむやだったような記憶があるので。じゃあ、
> ちょっと名前をまともにして(each_paragraphじゃなくてeach_sectionとかね)、
> 整備しましょう。
お願いします。
> >> - 設定画面のカスタマイズ(プラグインの設定をインタラクティブにする仕組
> >> み)
> >そこまで複雑なプラグインを作るんだったら、
> >設定画面をプラグインの実装者に丸投げしても良いのではないですか？
> >
> >プラグインの実装者はリンクのパスをTDiary側に渡すようにし、
> >TDiaryConfが設定画面でそれぞれのプラグインの設定画面へのリンクを作っておきます。
> >
> >問題はパスワードの扱いですが、プラグインの設定をするcgiスクリプトを
> >もう一つ作って、それを通してのみ設定できるようにすれば、.htaccessをいちいち
> >追加しなくて済みます。新たに作ったcgiスクリプトはCGI変数によって使用する
> >eRubyファイルを変化させれば、。tDiary側はプラグインの設定画面を作る時の
> >雛型となるeRubyファイルを提供するだけで良くなります。
> >
> ># セキュリティ面で問題がでるかなあ。
> >
> >設定画面をカスタマイズすることはできても、設定された値をcgi側のtdiary.confに残すのが
> >難しいと思います。すくなくともtdiary.rconfを使う今の方法では
> >無理な気がします。(実行時に動的にtdiary.rconfを変更すればできるかな。)
>
> 画面は丸投げというか、skelに何かファイルを入れてもらう方向でいいと思っ
> ているんだけど(これなら専用のCGIにする必要はない)、あとは標準の設定画面
> 中にメニューが増やせて、入力されたオプション値をtDiary側に渡せればいいの
> で、そんなに面倒な話ではないかな、と。ちなみにプラグインのオプションは
> @optionsハッシュに入れる決まりなので、受け渡しのルールも簡単でしょう。
なるほど。
> >国際化はします?
>
> うへー(笑)。設定画面を除けば、現時点でもプラグインだけでほぼ国際化は可
> 能だと思う。もちろんコンテンツが国際化されるはずはないので、日記ごとに対
> 応する言語が一意に決まるという意味でだけど。
>
> あとは誰かがドキュメントさえなんとかしてくれれば(笑)。
まだ半分くらいですが、readmeのそれらしいのを添付しておきます。
あと、例によって、tdiary-hnf-0.6.0 + tdiary-1.5.0.20020806 のデモを自分の
ところでやっています。
http://jurader.s1.xrea.com/tdiary/
試したかぎりでは、tDiary-1.5系も@ioクラスより上位の部分は
それなりに使えるようになってきていると思います。
******************************
NISHIO Mizuho
e-mail gha@intrastore.cdc.com
|