AutoTicketLink 外部チケットへの自動リンク†
- ページ: BugTrack
- 投稿者: umorigu
- 優先順位: 低
- 状態: 完了
- カテゴリー: 本体新機能
- 投稿日: 2017-02-22 (水) 07:16:14
- バージョン: 1.5.1
- リリース予定バージョン: 1.5.2
メッセージ†
InterWikiLinkの書式を使わず、地の文章の中で特定のパターンの文字列を外部システム(主にITS)の特定ページへのリンクにしたい。
(例: issue:2420 と書くと BugTrack/2420 へのリンクになる)
- (a)
JavaScriptファイル名 (PukiWiki本体標準のJavaScriptロジックを1ファイルで提供する)
- すべてのロジックを skin/main.js に統合しました
- (b)
keyに使える文字の明確化 済(2017/04/03)
- (c)
仕様のドキュメント化 official:AutoTicketLink
- (d)
リンクのTitleの実装 済(2017/04/03)
コメント†
コメント: デザインに関して†
- こんにちは。プラグインの記法を &color(); *1 とするか、 &color() *2とするか、という過去の静かな争いを思い出しました*3。機械可読性を下げる方向の記法は、そのコンテンツの寿命とトレードオフの関係をもたらすと思っています。所定のサイトや所定の区画だけで使えるようであれば両立できるはずです。 -- henoheno
コメント: 名称について†
- この機能は AutoTicketLink という名称にしたいと思っています -- umorigu
- 文字コードに依存しない文字であることを前提とした引数を一つ取って、URLの一か所をクライアント側で動的加工して、最終的に特定パターンのテキストにハイパーリンクの装飾を動的に行う、というシンプルかつ軽量な実装の名称が AutoTicketLink であるという点については、デザイン上のターゲットを示すものとしてまとまっていると思います。 -- henoheno
コメント: JavaScriptによる自動リンクの実装について†
- JavaScriptで仮実装しました。 github.com/umorigu/pukiwiki.autoticketlink Webブラウザ側で処理するのでサーバー側、既存実装の変更は少なくできると思っています。 -- umorigu
- skin/pukiwiki.skin.php に <script src="skin/ticketlink.js"></script> を追加します。あとはInterWikiのようにPukiWiki本体側(サーバー側)でサイト定義を設定できるようにしたい
- こんにちは。InterWikiをJavaScriptで外部に実装したようなモノのようですね。nodeValueが*4キモのようですが、値が安全に取り出されていてnullでないことは保証(validate)されていますか?menubarはどうされたいのでしょうか。 -- henoheno
- はい。機能はInterWikiに近いです。/\S/.test(e.nodeValue) でチェックしているつもりでしたが、/\S/.test(null) は true になってしまいました。さすが鋭いですね。対応します。menubarは特に特別扱いせず、処理対象です -- umorigu
- 更新しました -- umorigu
- e.nodeValue が null の場合の対処と、サイト情報を配列で定義できるようにしています。;
- validateの話題や、ignoreTags はいつか突然whitelist方式にしなければならなくなるかもしれないといった懸念はあります。 -- henoheno
- 外部JavaScriptファイルskin/ticketlink.jsを追加されているようですが、今後JavaScriptを増やす可能性があるのなら、skin/pukiwiki.jsのような名称の1ファイルに全てのJavaScriptを納めた方が良いと思います。ファイル数が増えるとHTTPリクエストが増えてしまうので。 -- Yorkfield
- <script src="skin/ticketlink.js"></script> はページ描画をブロックするので、</body>の直前が望ましいと思います。 -- Yorkfield
コメント: PHPとJavaScript間のデータ受け渡し†
- PukiWiki本体側を含めて実装しました。 commit:b351d0f966 -- umorigu
- 時間が無いため、雑なコメントになることをお許しください。 -- henoheno
- 今回は、PukiWiki本体に設定が統合され、フッターに出力しておいたspanタグを経由して、それがJavaScriptへ入力される方向の改訂が行われております。これは、JavaScriptのようなプログラム部分に設定を置きたくなかった、また、ユーザーごとに異なる設定を利用できるようにしたかった、というお気持ちから発したものだろうと推測します。 -- henoheno
- ただし、それによって『テキストファイルに「issue:1239」といった文字列があったならば、それをサーバー側で動的に置換してInterWikiとして処理させる』といったハックに比べると、転送量やロード時間、受け入れられる文字コードの種類、JavaScriptへの依存性などの点で、これまでのメリットが薄まってしまっているように思います。(このハックは、今思いついたものです) -- henoheno
- クライアント側での(WebブラウザのJavaScriptによる)処理にすることでご指摘のようなデメリットもあると思います。
一方で、(a)サーバー負荷を軽減できる。(b)DOMを利用できるので、処理がシンプルになる(PHPではWikiテキスト、またはHTMLそのものを対象にする必要がある)。(c)安定して動作しているPukiWikiの本体処理に手を加えずに済む。のようなメリットもあります。
また将来的な話としては、クライアントから直接ITSにアクセスすることで、例えばチケットのタイトルを取得・表示するような拡張も考えられます。ブラウザが古かったりJavaScriptがOFFであると動作しないこともありますが、昨今JavaScript OFFの環境が少ないと想像されること、またそもそも想定するのが、そのWikiと関連の深いチケットシステムへのリンクであり、例えば jira:PKWK-2420 のような文字列があればリンクされていなくてもJIRAのチケットであることは容易に判別できます。JavaScriptが動作しなくとも(リンクにならず、PlainTextのままでも)十分に意味は伝わります。 -- umorigu
- そして、どうしてもリンクされないと意味がない場合はInterWikiを使ってもよく、どちらを使うかは完全に管理者の意志で決定できます。
サーバー側ですべての処理を行うと、HTMLキャッシュを使った際にうまく動作しないケース(更新日時の目安表示など)もあるので、もう少しPukiWiki本体の処理もJavaScriptに持って行ってよいと思っています。 -- umorigu
- 気になったところをいくつかまとめてコメントします。 -- Yorkfield
- <span class="pukiwiki-ticketlink-site" data-site="key=$key,type=$type,detail=$detail,name=$name,baseUrl=$base_url" /> ですが、spanは空要素(Void elements)ではないので閉じタグを付けなければなりません。(たまたま気づきましたがSite admin:の所にも空p要素がありますね。) -- Yorkfield
- これは知りませんでした。修正します。(Site admin については別の機会に) commit:c97f4f88fe -- umorigu
- 私も気づいたときは確証は無かったのですが、www.w3.org/TR/html5/syntax.html#start-tags (8.1.2.1 Start tags)を確認してみると /> が許されるのはvoid elementsとforeign elementだけでした。(おそらくですが、古いブラウザが /> を無視すると想定しているのではないかと。) -- Yorkfield
- どこかでkeyは英数字のみに限定するなどした方が良いかもしれません。今はpukiwiki.ini.phpで正規表現が指定できてしまいます。(正規表現を使う用途があるならこのままもあり?) -- Yorkfield
- 鋭いですね。実際に使ってみると"."や"-"は使いたくなるので少し悩んでいました。正規表現は不要だけどいくつかの記号は使いたいという意味で。記号を許してしまうと jira: と asf-jira: があった時にどちらが選ばれるか、実装依存になってしまいます。これは制約にするしかないか...いずれにしても管理者がコントロールできる範囲ではあるので大きな問題にはならないと考えています。 -- umorigu
- keyに使える文字を 英数字、"-","." に限定しました commit:95306d1416 -- umorigu
- data-site属性経由で設定を渡していますが、JavaScriptの代入文を生成した方がJavaScript側で解析する必要がなくなって良い気がします。ただ、代入できるようにグローバルオブジェクトを1つは作らないといけないのでこの方法が絶対に良いというわけでも無いですが。 -- Yorkfield
//JavaScriptの代入文例
pukiwiki.ticketlink.list = [{key:"phpbug",type:"redmine",detail:"",name:"PHP :: Bug #$1",baseUrl:"//bugs.php.net/bug.php?id="}];
- JavaScriptの文にすると動的に<script>タグを挿入する必要があるので、できれば避けたいです。HTMLとエスケープ方法が違うのでセキュリティバグの発生しやすい部分になります。ただ、data-site属性のフォーマットが独自のものになっている点はメンテナンスに難があるのでJSONにしてみます。これでParseもしやすくなります。デメリットとして人から読みにくくはなってしまいますが --- umorigu
- はい、<script>タグの生成にリスクがあるのはその通りですので、無理にこの手段を取ることもないと思います。(エスケープについてはjson_encodeでなんとかならないかなと考えていましたが、2種類のエスケープが混在するとミスもしやすくなりそうです。)data-site属性のフォーマットをJSONにするのは良い案だと思います。 -- Yorkfield
- まずJSONに対応しました commit:fa378b39be -- umorigu
コメント†