WiLiKi:WishList:pending

WiLiKi:WishListに上げられたもので、 何らかの理由により採用が見送られている、 もしくは先伸ばしにされているもの。

• Zu 2004/02/24 18:49:13 PST
  • 右上にある編集とか編集履歴とかを「ページの中に書きたい」場合はどう書くのがスマートでしょうか。長いページの時に欲しくなったもんで。 reader-macro に しちゃうのが正解かな? URL全部書くのはつらいし。
  • Shiro: reader-macroがいいと思います。あまり一般化できなさそうなので。 wiliki:top-link等の細かい関数を個別に呼んでもいいですし、 wiliki:menu-linksを呼んでも良いでしょう。「現在フォーマッティング中のページ」 はwiliki:current-pageで取れます。(ただ、includeされているページを処理中は wiliki:current-pageはincludeされている側のページになっているので 注意が必要です。)
  • Zu (2004/02/26 03:13:44 PST) includeは見なかったことにして(^^; zu:WiLiKi/マクロ/Editと書いてみました。ありがとうございました。

• iriyak (2004/01/18 23:18:50 PST): ページの消去を実行した後にもう一度その名前で新規ページを作成して編集履歴をクリックしたら消去する前のページの履歴も表示されました。これがもし消去したタイミングで編集履歴も消えていたら有り難いと思いました。
  • Shiro (2004/01/19 03:28:28 PST): なるほど。 これには相反する考え方があって、「履歴をすべてとっておく」&「ページ名がキー」 という方針からすると、古いページの履歴が出てくることは正しいふるまいと 言えます。そうでないと間違えて消したor消されたページの復活もできませんし。
  • 同名だけど全く無関係なページにしたので履歴が邪魔…というのは、 「ページ名がキー」という方針にそもそも合わないわけですが、 現状では運用で逃げるしかない面もありますね。
  • 技術的にはログをスキャンして特定のページに関する情報を消去すれば いいんですが、ある意味、本来のWiLiKiのオペレーションからは外れた 操作ですので、WiLiKi本体で色々対応するより、別に管理用ツール(webベースでも コマンドラインでも)を作る方が良さそうな気がします。 WiLiKiの通常オペレーションとはちょっと違うメタな操作を行う 管理用ツールの必要性はなんとなく感じていたので。 (例えば、データベースのバックアップとか、パッキング(gdbmは明示的に パッキングをしないと、追加・消去を繰り返すとdbmファイルが次第に 大きくなる)とか。
  • iriyak (2004/01/19 18:49:39 PST): 管理用ツールで提供される機能で全然構いません。二つの大方針について異論はありません（ロールフォワードは必要ですし）。自分の公開サイトに公開したくなかった情報（基本認証をとく情報が含まれるＵＲＬ）を誤ってコミットしてしまったのがそもそものきっかけでした。こういう場合はイレギュラー処理として通常オペレーションとは別に切り出して問題ないと思います。頻度からして。
  • Shiro (2004/01/19 19:36:31 PST): ああなるほど。そりゃ履歴が見えたら嫌ですね。 他にも、履歴が残ることを狙ったspam的な書き込みなんかが発生する可能性も ありますし、何らかの対策は必要ですね。 緊急対策としては、コミットログを手で編集する方法があります (編集中はwiliki.cgiを止めとくと良いでしょう)。 コミットログはテキストで、'C "ページ名"' で始まる行から'.'だけの行 までが1エントリなので、該当するページの情報を全部切り取ってしまえば 表示されなくなります。
  • iriyak (2004/01/19 22:25:33 PST): Shiroさん、ワークアラウンドをお教えいただきありがとうございます。当面はメインユーザはアドミン兼の私ですのでコミットログの手動削除で運用していこうと思います。
  • iriyak (2004/01/20 20:56:35 PST): ワークアラウンドで過去履歴の消去に成功しました。どうもありがとうございました。

• Makoto (2003/12/17 17:47:24 PST): 皮をかぶせる機能として次のようなものはどうでしょうか？ 皮とは、WiLiKiページ本体の外側のHTMLのことです。

• wiliki.cgiで、headerとfooterとして*.scmファイルを指定できるようにする。
• headerやfooterに指定された*.scmファイルには、CGI環境のオブジェクトが 渡される(リクエストに基づいて動的なheaderやfooterを表示したい場合)
• headerやfooterが返すのは、最後にtree->stringして文字列にしたほうがいいかも しれません。というのは、WiLiKiページをtableの中に入れたいような場合、 headerの最後が<td>、footerの最初が</td>となるかもしれないからです。 あるいは、gawa(皮)を1つ指定できるようにして、そのある部分にWiLiKiページが 入るようにすれば、text.html-liteのみを使ってうまくwrapできるかもしれませんね。

• こういう機能があると、http://www.ruby-lang.org/ がtDiaryベースでできている、 ようなことも簡単になるかと思います。見た目が大幅にいじれると。

• その時、編集用リンクをWiLiKiページ本体か、headerあるいはfooterに入れるかを ちょっと悩みますが。

• Shiro: ちょっとad-hocな感じがしますね。むしろ、 format-pageメソッドをユーザがspecializeするって方向がいいんじゃないかなあ。 修飾がheaderとfooterだけとは限らないわけですし。

• Makoto (2003/10/30 19:40:07 PST): 脚注機能が欲しいです。

• Shiro (2003/10/08 04:47:09 PDT): 表示フォーマットのカスタマイズに関する機能は、 0.4のリリース後に、包括的に考えます。たぶん表示に関するベースクラスを 作って、カスタマイズはメソッドによって行うとか、そんな感じになると 思います。

• cut-sea:2004/09/09 19:52:41 PDTWiKiの形式を無視するクウォートって導入できないかしらん。 例えば、`...`で括った中はWiKiNameの形式になってても無視とか。 たまに「〜％って書いた時に…」とかの話をしたい時に全角で書くのはちょっといやん。
  • Shiro(2004/09/10 02:33:15 PDT): ふむ。あるいは

    ~''''''%
    

    と書くか、ですね。 マークアップを増やすのはコーディングとしては難しくないですが、 Wikiのメリットであるシンプルさを失っても余りあるかを考えないといけません。 今回は微妙ですねぇ。マークアップを無視したい代表例である、 Wikiマークアップのソースに言及する場合は {{{...}}} が使えるわけですし。

• shelarcy(2004/08/19 00:14:38 PDT): mixi で社内文書用にページの PDF 化機能があるから FreeStyleWiki を使うっていう人がいるのを見かけましたが、WiLiKi でも是非そういう機能が欲しいって方はどのくらいいるんでしょうか？
  • Zu あー、あるとうれしいです
  • Shiro WiLiKi内でpdf変換を抱えることはしないと思いますが、 wilikiモジュールがマークアップ→SXML変換に使えるので、SXML→PDFのツールを 使えばpdf化は可能ですね。kahuaにそういうコードがあったと思います。

• SHIMADA (2003/07/26 05:46:46 PDT): PREブロック（行頭空白）の中では、~% によるラインブレイクは無効になっていたほうがいいのではないでしょうか。Schemeのコードに出てきたときにエスケープが必要になりますし。
  • Shiro: まあ、不要といえば不要なんですが… あまり規則に例外を 設けたくないというのはあります。今のところ、行頭空白によるPREブロック中では 他のフォーマッティングルールも有効ですんで、「これとこれは使えるけど、 これとこれは使えない」というふうにするのはなんとなく避けたいなあ。 PREブロックで見出しやリストが使えないのは、シンタックス上排他的ですから 自然なんですが。なお、プログラムリストを入れる時はverbatimブロック 推奨です。

• Zu: 2003/06/11 14:04:59 PDT マクロを自分で追加したい場合は、どのようにするのが普通なのでしょうか。試行錯誤すがよくわからず、いまは macro.scm を書換えて使っています。
  • Shiro (2003/06/12 01:55:40 PDT): ねるWiki:WiLiKiあたりでちょっと話題になったこともありましたが。 まだ決まった方法は無いです。macro.scmを書き換えるのが気持ち悪ければ、 次のようなmymacro.scmを作ってmacro.scmと同じディレクトリに置き、 wiliki.cgiの中で(use wiliki.mymacro)とする、とか。

    ;; custom macros
    (define-module wiliki.mymacro
      (extend wiliki))
    (select-module wiliki.mymacro)
    
    (define-reader-macro (mymacro arg)
      ....)
    
    (provide "wiliki/mymacro")
    

  • Zu: 2003/06/12 07:02:49 PDT この方法でうまくいきました。ありがとうございました。と、書いたあとでいじってたらまたおかしくなった...(;;)
  • 今(2003/08/01 11:32:05 PDT)のCVS版でもこの方法でうまくいきますか? 何度か試したのですがうまくいかなくて...
  • Zu: 2004/01/25 20:43:27 PST これでできました。(extend wiliki.macro) がないと、define-reader-macroなどが見えないようです。

    ;; custom macros
    (define-module wiliki.mymacro
      (extend wiliki))
    (select-module wiliki.mymacro)
    (extend wiliki.macro)
    
    (define-reader-macro (macrotest arg) ...)
    (define-writer-macro (macrotest2 arg) ...)
    
    (provide "wiliki/mymacro")
    

• "[->English]" のリンクさきが、日本語とは別の英語ページになっていてほしい。 いまの動作(仕様？)は翻訳エンジンのようなものを組込むことを想定しているのですか？ --nobsun(2002/03/10 19:19:06 PST)
  • もともと、データ自体はmultilingualで持っておいて、表示時に指定の言語だけ 表示するような機能を考えていました。例えばデータはこんな感じ：

           =en
           This is the description in English.
           =jp
           日本語での説明です。
           =common
            (define (y f) ((lambda (x) (f (x x))) (lambda (x) (f (x x)))))

• あっ。なるほど、これはこれで便利ですね。--nobsun
• この方法は翻訳をするときにとても便利で、実際私も普段の翻訳時には こういうタグを付けて書いていって後から日本語だけ抽出するスクリプトを 使っています。ただ問題は、これだと英語オンリーの人には編集不可になって しまうことです。あと、ページタイトルが切り替えられないって問題もありますね。 やっぱり別ページの方がいいかなあ。Shiro (2002/03/10 22:41:44 PST)

• 専用Editing client
  • WiLiKi:EmacsClientの方で考察します。

• 一覧で、各ページの下に見出し・小見出しがリストアップされるような機能。Global な詳細目次のような感じで、使いやすいと思う。(DB が膨らむと大変かな。。。) --yari
  • 自前で見出しと$$tocマクロを並べれば、目次みたいなことはできます。 全ページに対してやるのはちょっと重くなりそうです。