BugTrack/2275

[Architecture] Wiki text 関係のまとめ†

• ページ: BugTrack2
• 投稿者: henoheno
• 優先順位: 低
• 状態: 提案
• カテゴリー: その他
• 投稿日: 2007-09-24 (月) 11:29:01
• バージョン:

メッセージ†

Wiki の文法をプログラムから改変する場合の原則などの話題をまとめましょう。

コメント: 改行の扱い (tracker_listにおいて、表が崩れたり、意図しないWiki textが生成される原因)†

• cvs:plugin/tracker.inc.php (1.56) よりも前からあることなんですが、tracker_list の出力は表形式限定ではないので、official:質問箱4/46のようにcalendar_viewer を使っているみたいなレイアウトにすると改行するしないで問題があるみたいです。あ～、質問箱の例だと、contents のないofficial::admin/Newsのほうが（見た目）そっくりかも。 -- 2007-09-19 (水) 23:48:13
  • r1.56が主張している改行コードの件ですね。了解しました。コレは元に戻して、Tracker_list 側で面倒を見てあげればいけると思います。table形式の記法の(行の)中で あるならば str_replace("\n", ''); ないならば str_replace("\n", '&br;'); するイメージで良いのでしょう -- henoheno 2007-09-20 (木) 00:29:34
    • 上のだと質問箱の例のようなリスト構造とかはきびしいのでは。それともあきらめてもらう？ -- 2007-09-20 (木) 00:47:41
    • (1)「#tracker_list にWiki text を(再解釈させ)描画させる」ために、(2)「Tracker_list::_replace_item() が Wiki text の境界を突き抜ける事がある副作用*1」を手段として利用している様に見える部分の事ですよね。2の部分はデザインが崩れているので直すしかないです*2。2 という副作用狙いの用法については がまんしてもらう と同時に、副作用ではない形にデザインし直せないか考える のが真っ当な道なんじゃないかと思います。第三の解は、「以前のように」自己責任で戻す逆改造かな・・・ -- henoheno 2007-09-20 (木) 01:14:06
  • ・・・そうすると、てっきりうまく整理したと思っていた Tracker_field_textarea のpreg_replace() は一体・・・zzz -- henoheno 2007-09-20 (木) 00:40:13
  • テスト用に無駄な領域（一番下）を使いましたが、"\n" をそのまま使わずに'&br;' に置換える方法なら、table形式かどうかは関係ないと思います。$line_break の設定で'&br;' か'' かを決めるぐらいの方がいいかもしれません。
    ついでなんで書いておきますが、_replace_item() で'|' を'|' に置換えているのは、次の例のように

    : 定義|語 | 説|明文
    | インライン|要素 | インライ|ン要素 |

    項目名から置換えた時に意図しない場所で区切られてしまわない様にするためです。 本当なら、CSV形式の表組みの時は',' や'"' の置換えをするほうがいいのかもしれませんけど。 -- 2007-09-20 (木) 21:11:31
• もう少し考えて見ましたが、上の発言の「再解釈」や「再render」という表現は正しくないです。(前提: tracker_list は Wiki text を中間コードとして最初に生成し、それをXHTMLに変換する、というアプローチを取っています。ここで言うアーキテクチャとは、安定した仕組みを積み重ねる構築手法や、そうして構築されたモノの事を指しています) Wiki text の FormattingRules は基本的に行指向のアーキテクチャですが、tracker_list を含む一部のプラグインは「改行を適切にエスケープしていない」部分が存在しており、それがWiki textの世界(情報の構造)をしばしば予期せず破壊してしまいます。プラグインのそれぞれの部分はそうしたデザイン(アーキテクチャ)を適切にフォローしていない、という観点の実装漏れ(穴/抜けがある)と見なすべきなので、通常は無条件に改修対象となるでしょう。さもないと、当たり前ですが予期しない破綻を招きます。で、安定した状況を達成したとして、利点欠点を検討した上で、限定的に条件を緩和できないかどうか考える、という事は有効です*3。しかしアーキテクチャを壊す事を前提にした運用アイデアについては、慎重に自己責任でとしか言い様が無いのです。といった事を言いたいのですが、解り易く書いてる時間がとれてませんね・・・zzz*4 -- henoheno 2007-09-21 (金) 00:28:51

  | [x] | [x] | [x] |h
  | [x] | [x] | [x] |
  | [x] | [x] | [x] |
  //  [x] = こうした場所に改行が一つ以上挿入される可能性がある限り、
  //        このテーブル書式は破綻する可能性がある。
  //       「失敗する可能性が存在する」ことが根本的な問題なので、
  //        可能性を完全に無くさない限りは安定しない
  
  - foobar [x] foobar [x]
  -- foobar [x] foobar [x]
  -- foobar [x] foobar
  // [x] = 上同 (Wiki text で 表現され終わっているはず の、
  //       情報の構造 が改変されてしまう)

• r1.58 で、カンマ始まりのものも含めて、エスケープする様にしました。お試しサイトのコードも更新しましたので、試せます -- henoheno 2007-09-22 (土) 23:48:10

コメント†

• BugTrack
• 開発版
  • リポジトリ
  • 開発日記
• :CategoryDev
  • PukiWiki2
  • PukiWiki/1.5
  • PukiWiki/1.4
  • PukiWiki/1.3
  • メーリングリスト
  • 開発談義
  • 雑談
• 開発者向け情報
  • Books
  • プラグイン

最新の16件