プロジェクト

全般

プロフィール

機能 #1063

プラグイン着脱時にイベントが発生する機能

あひる 家鴨4ヶ月前に追加. 4ヶ月前に更新.

ステータス:
新規
優先度:
通常
対象バージョン:
開始日:
2017-08-12
期日:
進捗率:

0%

プラグイン名:

説明

プラグイン着脱時に何も起きないので、イベントを発生させる機能がほしい。
ので、作ります。

関係しているリビジョン

リビジョン 9c334755 (差分)
あひる 家鴨4ヶ月前に追加

とりあえずイベントを発火するようにした refs #1063

リビジョン 16b83248 (差分)
toshi_a 初音4ヶ月前に追加

PluginのspecをHashではなく専用のModelにした refs #1063

リビジョン 013a4fbd (差分)
toshi_a 初音4ヶ月前に追加

Spec ModelをTLに入れても大丈夫な感じにした refs #1063

リビジョン 7507e3a1 (差分)
toshi_a 初音4ヶ月前に追加

Retriever…何もかもが懐かしい refs #1063

リビジョン f7eeae4b (差分)
toshi_a 初音4ヶ月前に追加

Plugin::Spec#created にそれっぽい時間を返させる refs #1063

リビジョン 34965ff7 (差分)
あひる 家鴨4ヶ月前に追加

プラグインのロードイベントがspecのmodelを返すようにした refs #1063

リビジョン cdb92b5e (差分)
あひる 家鴨4ヶ月前に追加

RDoc 追加 refs #1063

履歴

#1 toshi_a 初音4ヶ月前に更新

イベントの引数はどんなのを通知する予定?plugin slugとかでしょうか

#2 あひる 家鴨4ヶ月前に更新

ちょうど悩み始めてました。

:"plugin_load_status_#{plugin_slug}" 

とかどうでしょう。

#3 あひる 家鴨4ヶ月前に更新

Plugin.call() の仕様をど忘れしたのであれですが、Plugin.call(:イベントスラグ, 着脱の状態(boolean), description)
とかできるといいのかな

#4 あひる 家鴨4ヶ月前に更新

最初のやつ、勘違いです。

Plugin.call(:plugin_load_status, plugin_slug, status, description)

がいいかも

#5 toshi_a 初音4ヶ月前に更新

プラグインのslugはイベント名としてvalidなので可能だけど、 #1061 ではイベント名を動的に生成するか迷った結果、イベント名は固定で(key, value)を引数としたんですが、理由としては

  • 動的に名前を生成すると、listenerを登録する時にエディタで補完が効きづらくなる(単一のトークンとなるため)
  • どのような設定が変更されたかを知りたい場合、イベント名が動的に生成されるとトラックできない

というのがありました。一方でこの方法だと

  • すべてのイベントがPlugin slugを確認するif式をもつ必要がある

という問題があります。とはいえ、このイベントを受け取る動機って、不特定のプラグインがロードされた時になにかしたいとかだと思うので、イベント名は固定が良さそうと思います

#6 あひる 家鴨4ヶ月前に更新

イベント名は固定で行こうと思います。

特に mikutter 的な命名規則がなければ、このイベントは plugin_load_status というイベント名にしようと思ってますが、いかがでしょうか。
引数は前述の通り、プラグインスラグ(string)・プラグインの着脱の状態(boolean)・詳細(string)を考えています。

#7 toshi_a 初音4ヶ月前に更新

細かい話だけど、pluginの着脱はイベント分けたい気がします。mikutterだと抽出タブやアカウントの追加、削除とかの単位でイベント分けてるので。

詳細とかをイベントとして送ってしまうのはいいですね。具体的にはどんな内容を想定してますか。specファイルのdescription?

#8 あひる 家鴨4ヶ月前に更新

まずイベント分けることに関してですが、賛成です。
plugin_load と plugin_unload って感じに分けますかね。
ついでにロードされてるプラグイン一覧取得もほしいですね。
ロードされてるやつ、されてないやつ含めて
これはまた別のチケットになりそうですが。

description については、着脱時の状態を送ろうかと考えてました。
description というより reason っぽいですが。
失敗した時の理由とかをいれておきたかったです。

#9 あひる 家鴨4ヶ月前に更新

成功時は spec ファイル丸ごと投げて、 失敗時は失敗の理由とかどうですかね
もしくは description は spec を返し、error の様なものを最後に持てば住み分けができそう。

#10 toshi_a 初音4ヶ月前に更新

思いついたことをまとめて書かなくて申し訳ないんだけど、イベントが現在形だと、そのイベントをフィルタで止めてしまえばプラグインのロードを止められそうな感じになるので、既にロードが終わったことを通知しているだけなら、過去形にしたほうがいいと思います。

あと知ってるかわからないけど、面白い裏技があって

Plugin[:extract] # => #<Plugin: slug=extract>

プラグインオブジェクトが既にあれば得られるんだけど

Plugin[:extract].spec # {:slug=>:extract, :depends=>{:mikutter=>"0.2", :plugin=>["gtk", "settings", "gui", "uitranslator", "skin"]}, ...

と、specファイルの中身得ることが出来ます(specファイルがない場合は、slugなどの基本的な項目を埋めたダミーのHashオブジェクトが返される)。
PluginオブジェクトはDiva::Modelとかではないのであまりイベントで投げたくないですが、specはHashなので付けてもいいかも。その場合、そもそもslugを投げなくても、specに入っているので要らないっちゃ要らないですね。
一方で、今のところはPlugin[slug]でこれだけの情報が得られるので、slugだけでいいという考え方もあります。

#11 toshi_a 初音4ヶ月前に更新

誰も知らないと思って投稿したらもう知っとったでござるか・・・

#12 あひる 家鴨4ヶ月前に更新

知らなかったでござるよ
load の引数に spec きてたので、それそのまま横流しすればいいんじゃねといった感じでした。

#13 toshi_a 初音4ヶ月前に更新

後はエラーを得たいというのは具体的にはどういうやつ?

#14 あひる 家鴨4ヶ月前に更新

どういった理由でロードされなかったか、ですね。
例えばそんなスラグなかったんやとかロードしようとしたけどプラグインの対応してるmikutterのバージョンちがうとか
そんなところです

#15 toshi_a 初音4ヶ月前に更新

プラグインをロードするには、 Miquire::Plugin.load を呼ぶけど、これの例外だか戻り値だか(曖昧)でエラー報告してくれるので、成否は取れますよ。ロードエラーは、結局プラグインをロードできてないので、そのことを他のプラグインが検出できることが有用なケースが思いつかないんですが、そういうのも欲しいですか

#16 あひる 家鴨4ヶ月前に更新

目の前のことだけ考えると、Plugin Reloader に必要です。
プラグインが入っているか、失敗しているのかなど、細かいことを色々やりたいので

将来的に有用かどうかはわかりませんが、プラグインのロード状態が把握できていると、このプラグインが入っている場合はこんなこと動作をさせるみたいなプラグインとか作れそう

#17 toshi_a 初音4ヶ月前に更新

それだったらやっぱり、Miquire::Plugin.loadがロードが正しく行えたかを返すので十分で、エラーをイベントで通知するのは有用ではないと思います。
いずれにせよ、プラグインのロード・アンロード後にそれを通知するイベントは有用だと思うので、それはmergeしたいです。

#18 あひる 家鴨4ヶ月前に更新

実装で悩んでます。

ロード・アンロードの際に、対象の spec が valid か確認していて、invaild だと false を返してロードしないといった仕様ですが、
この場合、失敗の際にイベントを発生させるべきか否か迷ってます。
・イベントは発生させるが、引数の spec は nil
・イベントをそもそも発生させない
など考えられますが、どういった実装だと好ましいでしょうか。

Spec モデルのロードの状態を持たせてしまえば、イベントを発生させた方がいい気がしますが、考えがうまくまとまりません。

#19 toshi_a 初音4ヶ月前に更新

plugin_loadedイベントは、新たなプラグインがロードされたことを通知するものなので、失敗したときはイベントを発生しないようにするのが良いと思います

他の形式にエクスポート: Atom PDF