How can a plugin listen to another plugin's events?

Is there an official (openAPI) way for plugins to communicate.

Something like

9 comments
Comment actions Permalink

Alain Ravet wrote:

Is there an official (openAPI) way for plugins to communicate.

Something like

     listener =  ListenersRegistry.listenTo ("ThisPlugin","ThisEvent");
> ]]>

Nope for the moment. Coming really soon.

--
Maxim Shafirov
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

Hello Alain,

AR> Is there an official (openAPI) way for plugins to communicate.

As far i know, in Irida classloader you can define depended plugins. So,
then it done, you can use open api of other plugin and attach listeners.

Thanks!
--
Alexey Efimov, Java Developer
Tops BI
http://www.topsbi.ru

0
Comment actions Permalink

Alexey,

> As far i know, in Irida classloader you can define depended plugins.
> So, then it done, you can use open api of other plugin and attach
listeners.



I'm not sure it would work for what I have in mind (but I could be
wrong, as I've never touched what you're talking about).
The way I see it, "listenedTo" plugins would need to
- publish the list of accessible actions/events, and
- give access to those actions, through generic listeners.

Example: the TDDplugin.
- I'm writing a little SoundAndVoicePlugin, to have IDEA tell me (sound
or voice) when the TDDplugin button turns from green to orange, or
orange to green.
- Somebody else could write another plugin - ex: StatsCollectorPlugin -,
to listen to the same events of the same plugin, but for a different
purpose.
There is no dependency at all here, just optional means of
communication. I could be wrong though.

Alain


0
Comment actions Permalink

Hello Alain,

AR> The way I see it, "listenedTo" plugins would need to
AR> - publish the list of accessible actions/events, and
AR> - give access to those actions, through generic listeners.
AR> Example: the TDDplugin.
AR> - I'm writing a little SoundAndVoicePlugin, to have IDEA tell me
AR> (sound
AR> or voice) when the TDDplugin button turns from green to orange, or
AR> orange to green.

I think, that TDD plugin must have api for such listening? I'm wrong?
Then you may say in plugin.xml that your plugin is depends on TDD plugin
version N.
IDEA look that dependencies for your plugin and share classes from TDD plugin
to access from your plugin.
In your plugin, you will invoke TDDListener.addListener(yourPluginListener).

Thanks!
--
Alexey Efimov, Java Developer
Tops BI
http://www.topsbi.ru

0
Comment actions Permalink

Alexey

(Sorry for the length of this message, but it has to be long. You may
wish to print it)

> I think, that TDD plugin ..

It was just an example, to illustrate the communication, and reuse need.
Any plugin should/could be listened to, at a low cost for its author.

> I think, that TDD plugin must have api for such listening? I'm wrong?
> Then you may say in plugin.xml that your plugin is depends on TDD
plugin version N.

That wouldn't work very well: you'd have to update your listening plugin
each time you would want to listen to a new plugin, or each time such a
plugin would change (publish a new event)

What I have in mind is much more dynamic, and more "auto-discovery"
oriented.
=> it could be used as well programmatically, as declaratively (see below)


programmatic usage example:
-



example: print a message every hour:
-


It requires 1 plugin: the AlarmClockPlugin.


myHourMonitorListener = new Listener (){
public action (Object event) {
System.err.println ("another hour has passed");
}
}



PluginListenersRepository
. for ("AlarmClockplugin")
.addListenerFor("anotherHourEvent", myTimeOverlistener);





declarative usage example:
-


As strings are used to represent all the published info to all the
events emitters, and to all their events, and all their actions,
==> you can decide to use it, and what to do with it, at runtime.
====> you can build, or rather assemble, new plugins dynamically,
through a visual editor, without writing a single line of code. (Let's
call them dyna-plugins).

Note: IDEA would of course its interface accessible like in the example
above (through strings selections)


Note: plugin can publish
- events, that can be listened to
(Ex: projectCommitPerformed, emailSent, alarmTriggered)
- actions, that they can perform
(Ex: sendEmail, triggerAlarm, commitProject)
Note: the actions can have string parameters (see below)




********************************************************************************
example : create a dyna-plugin that sends an email to the CVS manager
, each time you commit the project
********************************************************************************

This would require
- IDEA to publish its VCS events, the same way I suggested above that
plugins would publish their public events.
- an EmailSenderPlugin, to send a text message,
and
- a visual editor, to create the logic (workflow) of the dyna-plugin.
Let's call it the "DynaPluginsEditor"
(it's a plugin, of course.)

step 0:
-


call the DynaPluginEditor + select "New"

=> 1/ a blank area appears, where you will assemble your dyna-plugin
It looks like a basic drawing program, that would only let you draw
rectangles and straight lines.

A rectangle will represent
- any of the plugins that have published their interface,
or
- IDEA, because it would also pubish its interface this way



step 1:
-


Drag 2 rectangles on the blank surface, and position them side to side,
with some space between them.

rectangle 1 = IDEA
rectangle 2 = the EmailSenderPlugin

each rectangle has :
- a left plug :'input', == its triggerable actions
(ex. 'sendEmail', for the EmailPlugin rectange)

- a right plug :'output', == its listenableTo events
(ex. VcsCommitPerformed, for the IDEA rectangle)



step 2: join IDEA.output -


> input.EmailSenderPlugin
-


graphically, you draw the shortest line between the 2 rectanges, and
connect it to their plugs.



step 3: specify IDEA.output
-


******
- click on the left rectangle (IDEA) 'output' plug
==> a list of all the listenable events appear
=====> select "CVSprojectCommit"


step 4: specify input.EmailSenderPlugin
-


******
- click on the right rectangle 'input' plug
==> a list of all the actions offered by the EmailSenderPlugin appears
=====> select "sendEmail"

each available action (--> method call) published by a plugin, has a
list of string properties (--> method parameters)

In this case, you would specify the recipient address, and a short
message text.


step 5:
-


- press "save this dyna-plugin"
- press "load this dyna-plugin"

In the background, a listener for IDEA.VcsCommitPerformed is created,
and added to the EmailSenderPlugin 'sendEmail' action.


That's it.

Alain

0
Comment actions Permalink

JB, any comment about this idea?

Alain

0
Comment actions Permalink

Alain,

We're developing new plugin system right away which will allow to define
extension points/extensions (somewhat similar to what eclipse has). Seems
like your ideas would be feasible to implement there.

-


Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"

JB, any comment about this idea?

Alain




0
Comment actions Permalink

Maxim

We're developing new plugin system right away which will allow to
define extension points/extensions (somewhat similar to what eclipse
has).





Any news on that matter?

Alain

0
Comment actions Permalink

Kind of sounds like what Hivemind aims to do. It was used the eclipse mechanism for inspiration.

0

Please sign in to leave a comment.