function plugin_<プラグイン名>_usage() 仕様の追加†
- ページ: BugTrack
- 投稿者: @c
- 優先順位: 普通
- 状態: 提案
- カテゴリー: プラグイン
- 投稿日: 2004-08-09 (月) 13:02:02
- バージョン:
メッセージ†
function plugin_<プラグイン名>_usage() 仕様の追加
:目的:各プラグインの用法表示
- usage(0) :一行サマリーをテキストで返す
- usage(1) :バージョンやオプションの用法を含んだテキストを返す。
増え続けるプラグインのリソース管理低減を..
- こんにちは :) 特にサードパーティ製プラグインが問題でしょうね。ところで、この関数はどうやって呼び出す事をイメージされているのでしょうか？ -- henoheno
- この提案を受けて考えてみましたが、どのプラグインでも、同じ体裁で、同じ情報を統一した形式(man pageみたいな)で表示する。ということを考慮すると、pluginのクラスを作り、その中の usageメソッドに投げれば...のような実装と、文章に書く側(定義)とすれば、#と&と使ってきたわけなので、? なんかとか。?vote() のような。では、どうでしょうかね？ この提案だと、どう実装するの？ですからね。-- upk
- あと、なんで usage の前のアンスコが２つなのか？なので、実装するなら、convertやinlineなどと同様とする。でしょうかね？ -- upk
- 個々のプラグインで表示可能にする手もありますが、別途作成したプラグインを実行すると各プラグインの_usage()を全部読み取って PukiWiki/1.4/マニュアル/プラグイン みたいなのを生成してくれる、ってのはどうでしょう？ -- にぶんのに
- 個人的には、国際化のときに問題になりそうなのと、マニュアルは別の人が書いてもいいようにしてほしいために、プラグインファイル(<プラグイン名>.inc.php)の中にこの関数がはいるのは反対です。Wikiなのですから、Wikiページにプラグインヘルプを同梱するほうが形式ばらないし筋がいいとおもいますが・・・（見られたくなければ隠しページに書けばいいわけですし・・・） -- みこ
- ただし、どちらにしても（サードパーティの方も含めて）プラグインヘルプは必ず同梱してほしいのと、フォーマットは統一してほしいというのはありますけどね:) 現在のプラグインヘルプはWikiを利用するだけの人には分かりにくいのは事実なので(^^; （setlinebreak や update_entities などないのもあるし、言語ファイル設定・プラグイン内設定はWikiを利用するだけの人にはいらないし・・・） -- みこ
- そこで、逆に提案なのですが :config/plugin/<プラグイン名> があるように :help/plugin/<プラグイン名> にプラグインのヘルプがあり、上記の ?vote();*1 みたいな用途の必要があればそれを呼び出すというのはどうでしょう？ -- みこ
- plugin_(plugin-name)_man.ja.lngなどのファイルを同梱してもらい、それをja.lngで取り込む仕様を作成。とかはどうでしょ？ -- Ark
- うーん、lngを増やしても・・・結局lngの中の変数はどうやって決めるの？とかいろいろ問題が出そうな気がするのですが・・・ -- みこ
- 何気に盛り上がってますね :) 話の発端は「管理リソース」を低減するためのものだとわかりますが、ご提案自体は(情報を分散させる)仕様を追加する形になってしまっているため、既に問題となっている「内部リソース」を、減らすどころかむしろ増やす(PukiWikiの管理負荷を高める)副作用が問題だと思います。BugTrack自体のステータスは、最終的には「却下」になるかもしれません。 -- henoheno
- 今回のニーズ(管理リソースの低減)に対し、現状真っ先に取るべきアクションとしては、まずプラグインマニュアルの同梱でしょうね :) やらねば・・・。プラグインごとのヘルプページは管理者さんに便利そうですね。(プラグインの説明をページ名としてポイントしたり、設置しないプラグインの分を簡単に削除できるので) -- henoheno
- USAGEを表示する手法をプラグイン自体に組み込む話ですが、これはUnixのコマンド(CLI)の世界とそっくり同じだと思いますよ。従来より、calendar_viewerプラグインの様に異常な引数にエラーを表示するものもあれば、memoプラグインの様にオプションを与えることができないけれども、動かせば使い方がすぐわかる物もあります。引数が空だったり '-h'ならUSAGEを表示する、といったものがあっていいはずです。すなわち基本は個別対応という事になっているはずです。 -- henoheno
- 別の意味では従来のプラグインはもう少しユーザーフレンドリーになる事ができるはずで、ここ数日いじっている includeプラグインや calender_viewerプラグインはそのあたりを意識して直しています -- henoheno
- Arkさんの案は、プラグインレベルの多言語化と、内部リソースの集中に対処できそうな、興味深い案だと思います。ただプラグインの数だけファイルを作ると死にそうなので、今は plugin.ja.lng / 同 en.lng くらいにしませんか (^^; -- henoheno
- 使い方の話なので、今あるプラグインヘルプページを加工してしまうだけで、基本なモノは終わると思うのですが・・・。プラグインヘルプページに無いモノを適宜追加していくだけなのでそんなにたいした作業量にはならないかと思います。ヘルプページの作りこみは後に回してでもいいと思いますし。中の変数の問題は変数のスコープがローカルになるので問題にはならないかと。 -- Ark
- うーん(^^; 論点の違いになりそうでこわいけどコメント。開発チームから見たら、加工して文章を作るのもそれをどうやって表示するのか示すのも大変だとおもうんだけど(^^; （本当はマニュアルチームみたいな人がいると開発チームは助かるんですけしょうけどね・・・） -- みこ
- わたしが提案したものはPukiWiki Plus!に仮実装してみました。（サンプル） -- みこ
- 多くの反応があり、嬉しく思います。 さて、私はこれは作成プラグインの追加仕様とし、用法はversionlistプラグインの様な利用法を想定しております。plug_man()とか,plug_man('calendar2')..
表示言語は、暗示的には環境変数LANGを参照、明示的にはplugin_(plugin-name)_usage([msgtype],[Lang])の様な仕様を追加で、いかがでしょうか？、どのサイトのpukiwakiに次々と発表されるサードパーティのプラグの、どのバージョンが実装され、どの様なオプションになっているかの把握が、プラグインのマニュアルを探さず、ソースから取得できる事のメリットは大きいと考え、コミット致しました。 -- @c
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
