Project

General

Profile

機能 #1063

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

Added by あひる 家鴨 over 2 years ago. Updated over 2 years ago.

Status:
新規
Priority:
通常
Target version:
Start date:
2017-08-12
Due date:
% Done:

0%

プラグイン名:

Description

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

Associated revisions

Revision 9c334755 (diff)
Added by あひる 家鴨 over 2 years ago

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

Revision 16b83248 (diff)
Added by toshi_a 初音 over 2 years ago

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

Revision 013a4fbd (diff)
Added by toshi_a 初音 over 2 years ago

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

Revision 7507e3a1 (diff)
Added by toshi_a 初音 over 2 years ago

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

Revision f7eeae4b (diff)
Added by toshi_a 初音 over 2 years ago

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

Revision 34965ff7 (diff)
Added by あひる 家鴨 over 2 years ago

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

Revision cdb92b5e (diff)
Added by あひる 家鴨 over 2 years ago

RDoc 追加 refs #1063

History

#1

Updated by toshi_a 初音 over 2 years ago

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

#2

Updated by あひる 家鴨 over 2 years ago

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

:"plugin_load_status_#{plugin_slug}" 

とかどうでしょう。

#3

Updated by あひる 家鴨 over 2 years ago

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

#4

Updated by あひる 家鴨 over 2 years ago

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

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

がいいかも

#5

Updated by toshi_a 初音 over 2 years ago

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

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

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

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

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

#6

Updated by あひる 家鴨 over 2 years ago

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

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

#7

Updated by toshi_a 初音 over 2 years ago

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

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

#8

Updated by あひる 家鴨 over 2 years ago

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

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

#9

Updated by あひる 家鴨 over 2 years ago

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

#10

Updated by toshi_a 初音 over 2 years ago

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

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

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

Updated by toshi_a 初音 over 2 years ago

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

#12

Updated by あひる 家鴨 over 2 years ago

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

#13

Updated by toshi_a 初音 over 2 years ago

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

#14

Updated by あひる 家鴨 over 2 years ago

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

#15

Updated by toshi_a 初音 over 2 years ago

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

#16

Updated by あひる 家鴨 over 2 years ago

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

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

#17

Updated by toshi_a 初音 over 2 years ago

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

#18

Updated by あひる 家鴨 over 2 years ago

実装で悩んでます。

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

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

#19

Updated by toshi_a 初音 over 2 years ago

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

Also available in: Atom PDF