BugTrack/2420 の履歴差分(No.11)

追加された行はこの色です。
削除された行はこの色です。
#author("2017-03-13T23:48:22+09:00;2017-03-13T23:23:53+09:00","","")
#author("2017-03-18T01:41:52+09:00","","")
* 外部チケットへのリンクを行いやすくする [#k9115a28]

- ページ: BugTrack
- 投稿者: [[umorigu]]
- 優先順位: 低
- 状態: 提案
- カテゴリー: 本体新機能
- 投稿日: 2017-02-22 (水) 07:16:14
- バージョン: 1.5.1

** メッセージ [#w7fw328ed]
InterWikiLinkの書式を使わず、地の文章の中で特定のパターンの文字列を外部システム（主にITS）の特定ページへのリンクにしたい。

(例: bug:2420 と書くと [[BugTrack/2420]] へのリンクになる)

** 関連 [#gf186069]

- [[BugTrack/2002]] AutoAlias機能追加
-- [[BugTrack/2002#d03572b7]] 正規表現の直接指定によるAutoLink/AutoAlias


--------
- こんにちは。プラグインの記法を  &amp;color(); ((セミコロンあり)) とするか、 &amp;color() ((セミコロンなし))とするか、という過去の静かな争いを思い出しました((後発のWikiサービスが後者を採用していましたが、もう稼働していないはずです。まだありますか？))。機械可読性を下げる方向の記法は、そのコンテンツの寿命とトレードオフの関係をもたらすと思っています。所定のサイトや所定の区画だけで使えるようであれば両立できるはずです。 -- [[henoheno]] &new{2017-02-23 (木) 22:55:59};
- JavaScriptで仮実装しました。 github.com/umorigu/pukiwiki.autoticketlink Webブラウザ側で処理するのでサーバー側、既存実装の変更は少なくできると思っています。 -- [[umorigu]] &new{2017-03-09 (木) 08:19:46};
-- skin/pukiwiki.skin.php に <script src="skin/ticketlink.js"></script> を追加します。あとはInterWikiのようにPukiWiki本体側(サーバー側)でサイト定義を設定できるようにしたい
- こんにちは。InterWikiをJavaScriptで外部に実装したようなモノのようですね。nodeValueが((攻撃する時の))キモのようですが、値が安全に取り出されていてnullでないことは保証(validate)されていますか？menubarはどうされたいのでしょうか。 -- [[henoheno]] &new{2017-03-09 (木) 22:02:18};
-- はい。機能はInterWikiに近いです。/\S/.test(e.nodeValue) でチェックしているつもりでしたが、/\S/.test(null) は true になってしまいました。さすが鋭いですね。対応します。menubarは特に特別扱いせず、処理対象です -- [[umorigu]] &new{2017-03-09 (木) 23:28:27};
- 更新しました -- [[umorigu]] &new{2017-03-10 (金) 09:12:02};
-- e.nodeValue が null の場合の対処と、サイト情報を配列で定義できるようにしています。
- PukiWiki本体側を含めて実装しました。 [[commit:b351d0f966]] この機能は AutoTicketLink という名称にしたいと思っています -- [[umorigu]] &new{2017-03-12 (日) 19:14:48};
- 時間が無いため、雑なコメントになることをお許しください。 -- [[henoheno]] &new{2017-03-13 (月) 23:21:54};
-- 文字コードに依存しない文字であることを前提とした引数を一つ取って、URLの一か所をクライアント側で動的加工して、最終的に特定パターンのテキストにハイパーリンクの装飾を動的に行う、というシンプルかつ軽量な実装の名称が AutoTicketLink であるという点については、デザイン上のターゲットを示すものとしてまとまっていると思います。validateの話題や、ignoreTags はいつか突然whitelist方式にしなければならなくなるかもしれないといった懸念はあります。 -- [[henoheno]] &new{2017-03-13 (月) 23:22:05};
-- 今回は、PukiWiki本体に設定が統合され、フッターに出力しておいたspanタグを経由して、それがJavaScriptへ入力される方向の改訂が行われております。これは、JavaScriptのようなプログラム部分に設定を置きたくなかった、また、ユーザーごとに異なる設定を利用できるようにしたかった、というお気持ちから発したものだろうと推測します。 -- [[henoheno]] &new{2017-03-13 (月) 23:22:15};
-- ただし、それによって『テキストファイルに「bug:1239」といった文字列があったならば、それをサーバー側で動的に置換してInterWikiとして処理させる』といったハックに比べると、転送量やロード時間、受け入れられる文字コードの種類、JavaScriptへの依存性などの点で、これまでのメリットが薄まってしまっているように思います。(このハックは、今思いついたものです) -- [[henoheno]] &new{2017-03-13 (月) 23:22:24};
-- クライアント側での(WebブラウザのJavaScriptによる)処理にすることでご指摘のようなデメリットもあると思います。&br;一方で、(a)サーバー負荷を軽減できる。(b)DOMを利用できるので、処理がシンプルになる(PHPではWikiテキスト、またはHTMLそのものを対象にする必要がある)。(c)安定して動作しているPukiWikiの本体処理に手を加えずに済む。のようなメリットもあります。&br;また将来的な話としては、クライアントから直接ITSにアクセスすることで、例えばチケットのタイトルを取得・表示するような拡張も考えられます。ブラウザが古かったりJavaScriptがOFFであると動作しないこともありますが、昨今JavaScript OFFの環境が少ないと想像されること、またそもそも想定するのが、そのWikiと関連の深いチケットシステムへのリンクであり、例えば jira:PKWK-2420 のような文字列があればリンクされていなくてもJIRAのチケットであることは容易に判別できます。JavaScriptが動作しなくとも(リンクにならず、PlainTextのままでも)十分に意味は伝わります。 -- [[umorigu]] &new{2017-03-18 (土) 00:02:04};
- そして、どうしてもリンクされないと意味がない場合はInterWikiを使ってもよく、どちらを使うかは完全に管理者の意志で決定できます。&br;サーバー側ですべての処理を行うと、HTMLキャッシュを使った際にうまく動作しないケース(更新日時の目安表示など)もあるので、もう少しPukiWiki本体の処理もJavaScriptに持って行ってよいと思っています。 -- [[umorigu]] &new{2017-03-18 (土) 00:23:45};
- 外部JavaScriptファイルskin/ticketlink.jsを追加されているようですが、今後JavaScriptを増やす可能性があるのなら、skin/pukiwiki.jsのような名称の1ファイルに全てのJavaScriptを納めた方が良いと思います。ファイル数が増えるとHTTPリクエストが増えてしまうので。 -- [[Yorkfield]] &new{2017-03-18 (土) 01:41:52};

#comment