鎌滝です。
;; スレッドが延び過ぎたので、いったん切ります。
今回行ったOOo QAサイトページ構成変更の作業を順を追って書いておきます。
1日目
- メニューの「整理済みのFAQ」にある「インストール」などのページに新し
いTrackerページのうち「完了」分を出力する記述を追加（データがない場
合は何も出力されないので、事前に書いておいても問題なく、作業後も以前
の記述が残っていても表示に影響しない）
- メニューの「回答へご協力ください」の2つのページも上記と同じ作業を行
う
- メニューの「FAQ登録」ページの内容を新しいTrackerページ用に変更
鎌滝です。
いろいろお騒がせしましたが、今日の作業は終えました。OOo QAの表示も、
ほぼ作業前と変わらないはずです。
今日は出かけますので、詳しくは後ほど報告します。
--
M.Kamataki
http://nstage.dth.jp/pukiwki/?OpenOffice.org
http://nstage.dth.jp/~kamataki/pb/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Masahisa Kamataki wrote:
いろいろお騒がせしましたが、今日の作業は終えました。OOo QAの表示も、
ほぼ作業前と変わらないはずです。
お疲れ様です。
FrontPage の表示にとても時間がかかる原因がわかってきました。
一覧表を出している #tracker_list っていうプラグイン？の作り方に改善の余地があるようです。
現在の方法
オリンピックの選手が 400 人演技しました。
その 400 人に厳密に時間順にならんでもらいました。
上位の 20 人を採用し、残りの 380 人には解散してもらいました。
改善の提案
自己レスです。
On 5/15/06, tora [EMAIL PROTECTED] wrote:
FrontPage の表示にとても時間がかかる原因がわかってきました。
一覧表を出している #tracker_list っていうプラグイン？の作り方に改善の余地があるようです。
同じような作業内容をシェルスクリプトでやったら、1秒もかからずできました。
そのプラグインの作者さんは、何から何まですべて PHP でやってのけているようです。
それはそれですごいです。尊敬しちゃいます。
とはいっても、プログラムの開発に使う言語も、適材適所ってことかもしれません。
鎌滝です。
At Mon, 15 May 2006 18:05:19 +0900,
tora wrote:
FrontPage の表示にとても時間がかかる原因がわかってきました。
一覧表を出している #tracker_list っていうプラグイン？の作り方に改善の余地があるようです。
現在の方法
オリンピックの選手が 400 人演技しました。
その 400 人に厳密に時間順にならんでもらいました。
上位の 20 人を採用し、残りの 380 人には解散してもらいました。
改善の提案
オリンピックの選手が 400 人、これから演技します。
鎌滝です。
訂正します。
さて、準備をはじめたいと思います。いろいろと考えると、厳密な手順を考え
ないといけませんね。
まず、次の作業をしましょう。
- faq/3/*** のためのページ設定（これは現在のfaq2のものを使います）
- faq/*** の最新の登録から20件を faq/3/*** へ移動
混乱する方がいらっしゃると思うので、これは止めます。トップページの表示
は旧tracker分を10件、新tracker分を20件というリストにしておこうと思いま
す。
- トップページへ faq/3/*** のための Tracker を設置
松井幹彦です。
みなさん、ありがとうございます。
お骨折りによって、希望通りに外部からのリンクが生きるようなので安心しました。
実はOOo QAを開始して、適度な重複は重要なデータになると思うようになり
ました。たとえば、同じ課題に対して違う表現の質問が複数あった場合、質問
される方の検索は、そのどれかに行きつく確立が高くなります。さらにページ
にあるリンクを辿ることで、本来の回答へ行きつけるようになるわけです。
これは、私も感じています。
無理矢理ひとつに統合するよりも、いろいろなアプローチのものをリンクさせて
おく方が有効だと思います。
Masahisa Kamataki wrote:
実はOOo QAを開始して、適度な重複は重要なデータになると思うようになり
ました。たとえば、同じ課題に対して違う表現の質問が複数あった場合、質問
される方の検索は、そのどれかに行きつく確立が高くなります。さらにページ
にあるリンクを辿ることで、本来の回答へ行きつけるようになるわけです。
それと、システムを複数設けることとは、別次元の議論です。
１つのシステムにおいても、過去ログを調べなければ、重複して投稿しますから、
お望みの状況は作り出せます。
複数のシステムにすることによって過去ログを調べ難くし、その結果、適度な重複が
tora wrote:
誤解があるといけないので書いておきます。わたしが限界と書いたのは、
Pukiwikiには1ページで表示できる容量に限界があるということです。Tracker
の登録数の限界ではありません。具体的には、どこに影響が出るかというと、
faqページに登録された質問の下記の一覧ページです。
http://oooug.jp/faq/index.php?%BC%C1%CC%E4%A5%EA%A5%B9%A5%C8
これ自体は、そもそもそのようなページの設計が悪いのではないでしょうか。
Masahisa Kamataki wrote:
誤解があるといけないので書いておきます。わたしが限界と書いたのは、
Pukiwikiには1ページで表示できる容量に限界があるということです。Tracker
の登録数の限界ではありません。具体的には、どこに影響が出るかというと、
faqページに登録された質問の下記の一覧ページです。
http://oooug.jp/faq/index.php?%BC%C1%CC%E4%A5%EA%A5%B9%A5%C8
tora wrote:
項目数が多くなるとエラーが発生するとおっしゃっていましたが、Pukiwiki のプログラム
Masahisa Kamataki wrote:
誤解があるといけないので書いておきます。わたしが限界と書いたのは、
Pukiwikiには1ページで表示できる容量に限界があるということです。Tracker
の登録数の限界ではありません。具体的には、どこに影響が出るかというと、
faqページに登録された質問の下記の一覧ページです。
http://oooug.jp/faq/index.php?%BC%C1%CC%E4%A5%EA%A5%B9%A5%C8
$ cat wiki/BCC1CCE4A5EAA5B9A5C8.txt
[[FrontPage]]
...
tora wrote:
# PHP を使っていながら、データベースソフトを使わないなんて。。。変なやつ。
ディレクトリの内容を単純にコピーしたら、移行できちゃった。
データベースソフトをあえて使っていないから、このような利点があるのですね。
http://x.tora-japan.com/oooug.jp/faq/
※個人的なテスト・開発・作業用です。
本物と間違えないように、背景を灰色にしています。
Tora
-
To
catchです
tora wrote:
最初の 100 件を表示し、[前へ] [ 1 2 3 4 ] [次へ] のようなボタンを用意しておくのが、
ごく普通のやり方のような気がしませんか。
おお、それはナイスかも。
# 問題となっているページの内容を作り出しているは、plugin/tracker.inc.php かな。
そうです。
たとえば、次のように記述すると、faq1というtrackerで登録したfaq以下のペー
ジを20件表示します。
#tracker_list(faq,faq1,_real:SORT_DESC,20)
鎌滝です。
At Mon, 15 May 2006 07:16:05 +0900,
Yutaka kachi wrote:
tora wrote:
最初の 100 件を表示し、[前へ] [ 1 2 3 4 ] [次へ] のようなボタンを用意しておくのが、
ごく普通のやり方のような気がしませんか。
おお、それはナイスかも。
# 問題となっているページの内容を作り出しているは、plugin/tracker.inc.php かな。
そうです。
たとえば、次のように記述すると、faq1というtrackerで登録したfaq以下のペー
ジを20件表示します。
catchです
Masahisa Kamataki wrote:
で、「ページの容量制限があるので、ページを分けましょう」という話になっ
た時、「じゃ、このタイミングで tracker の仕様を見直しましょう」という
ことになったわけです。具体的には、「分類」が増えています。旧ページに新
しい仕様の tracker を組み合わせるのは、リストの表示がおかしくなるので、
ページを分ける必然性が出たのです。この規定の方針にしたがって、わたしは
作業しているのです。みんな忘れてる。;-
ごめんなさい。m(_ _)m
# 問題となっているページの内容を作り出しているは、plugin/tracker.inc.php かな。
Masahisa Kamataki wrote:
書いていながらお気づきでないようですが、メスを入れるなら tracker でな
く tracker_list のほうです。tracker のほうは1ページずつ吐き出している
だけだから、基本的には無制限なはずです。
その通りっす。
勘違いしているわけではないという言い訳を少し。。。
機能名からでなく、実装しているソースコード側から見たらって話でした。
ファイルとしての
catchです
松井幹彦さん wrote:
現在のページおよび「oooug.jp/faq」内のリンクは変更できても、外部のサイト
のリンクまでは修正できないので、第三者のWebページや検索サイトからの参照
がエラーになります。ものがFAQだけに、その影響は大きいと思うのですが。
外部から、存在しないページを参照すると、編集画面が表示されますね。
readコマンドの説明によると、
指定したページを表示する。該当ページが存在しない場合は編集状態で開き、
ページ名がInterWikiであった場合は、その解決を行う。
鎌滝です。
とりあえずここに繋げます。
現在のQAが410番になったので、そろそろ限界です。
At Mon, 24 Apr 2006 00:58:14 +0900,
可知さん wrote:
ここが重要になるわけですが、「faq/faq1/***」ではいけないでしょうか。ペー
ジが決まれば、先にtracker用設定ページを作成しておけます。
「faq/faq1/***」でもOKだと思います。
こだわるようですが、
faq/*** → faq/1/***
faq2/*** → faq/2/***
新QA → faq/3/***
catchです
Masahisa Kamataki wrote:
鎌滝です。
とりあえずここに繋げます。
現在のQAが410番になったので、そろそろ限界です。
At Mon, 24 Apr 2006 00:58:14 +0900,
可知さん wrote:
ここが重要になるわけですが、「faq/faq1/***」ではいけないでしょうか。ペー
ジが決まれば、先にtracker用設定ページを作成しておけます。
「faq/faq1/***」でもOKだと思います。
こだわるようですが、
faq/*** → faq/1/***
faq2/*** →
松井幹彦です。
すみません、過去に話し合いがあっての結論なのでしょうが、
既存の「faq/**」「faq2/**」は変更せずに、「faq3/**」ではだめでしょうか。
現在のページおよび「oooug.jp/faq」内のリンクは変更できても、外部のサイト
のリンクまでは修正できないので、第三者のWebページや検索サイトからの参照
がエラーになります。ものがFAQだけに、その影響は大きいと思うのですが。
過去の話を把握できていない発言で申し訳ないのですが、取り急ぎ。
Yutaka kachi wrote:
catchです
Masahisa Kamataki wrote:
鎌滝です。
At Sat, 13 May 2006 05:45:31 +0900,
松井幹彦さん wrote:
すみません、過去に話し合いがあっての結論なのでしょうが、
既存の「faq/**」「faq2/**」は変更せずに、「faq3/**」ではだめでしょうか。
現在のページおよび「oooug.jp/faq」内のリンクは変更できても、外部のサイト
のリンクまでは修正できないので、第三者のWebページや検索サイトからの参照
がエラーになります。ものがFAQだけに、その影響は大きいと思うのですが。
過去の話を把握できていない発言で申し訳ないのですが、取り急ぎ。
OOo
松井幹彦です。
なるほど……。
では、両立する案として、『いままでのページは、念のために保存コピーとして
残した上で、新しいページで整理する』という方法はどうでしょう？
OpenOffice.orgは、このところいろいろなWebページで取り上げられています。
個人のブログなどでも「トラブルをこうして解決した」などの書き込みもあると
思います。そういったところのリンクがすべて途切れてしまうのが心配です。
Masahisa Kamataki wrote:
鎌滝です。
At Sat, 13 May 2006 05:45:31 +0900,
松井幹彦さん wrote:
私も過去の話し合いをよく読んでいないので恐縮なのですが、もう少し構成を考えませんか。
松井幹彦さん wrote:
現在のページおよび「oooug.jp/faq」内のリンクは変更できても、外部のサイト
のリンクまでは修正できないので、第三者のWebページや検索サイトからの参照
がエラーになります。ものがFAQだけに、その影響は大きいと思うのですが。
まず、松井さんからの指摘はごもっともだと思います。
鎌滝さんのご意見もわかります。そこで、、、
新しいディレクトリへ移行はするのですが、そのときに、Apache の Rewrite 機能または、
transfer
23 matches
Mail list logo
