Home » Language IDEs » Java Development Tools (JDT) » Extensions/points and events/listeners, differences?
| Extensions/points and events/listeners, differences? [message #131167] |
Sat, 03 January 2004 22:16  |
Eclipse User |
|
|
|
I am trying to figure out if there is any special handling through the
plugin.xml for a plugin to indicate it fires some user defined event it
provides and for other plugins to "tap into" listening for that event via
the plugin.xml file(s) they provide. In general, plugins are lazy created.
So if my plugin wants to fire an event that other plugins want to listen
for, how is that done? Do I provide an extension point and first create all
extensions, which each extension code of each plugin wanting to listen then
adds their listener? Or is there a more "automagic" manner in handling such
a common practice as this such that the eclipse plugin engine handles this
for me and I simply provide listener classes via plugin.xml extension
plugins?
Sorry if this is confusing, I am just trying to understand the correaltion
between extension points and extensions, and events and listeners. Is there
a specific difference when dealing with events and listeners? If I want my
"view" to fire off certain events, is the concept of events and listeners
null and void in Eclipse, replaced by the use of extensions and interfaces?
thanks.
|
|
| |
| Re: Extensions/points and events/listeners, differences? [message #131289 is a reply to message #131167] |
Mon, 05 January 2004 05:28  |
| Eclipse User |
|
|
|
Originally posted by: eostroukhov.hotmail.com
"spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
news:bt80fs$blt$1@eclipse.org...
> I am trying to figure out if there is any special handling through the
> plugin.xml for a plugin to indicate it fires some user defined event it
> provides and for other plugins to "tap into" listening for that event via
> the plugin.xml file(s) they provide.
I believe, no.
> In general, plugins are lazy created.
> So if my plugin wants to fire an event that other plugins want to listen
> for, how is that done? Do I provide an extension point and first create
all
> extensions, which each extension code of each plugin wanting to listen
then
> adds their listener? Or is there a more "automagic" manner in handling
such
> a common practice as this such that the eclipse plugin engine handles this
> for me and I simply provide listener classes via plugin.xml extension
> plugins?
There is no automated way to work with listener. In general, when you start
your plugin you should manually walk the extensions and add them as
listeners (i.e. instantiate classes or lookup initialized instances in some
well-defined places, etc.
> Sorry if this is confusing, I am just trying to understand the correaltion
> between extension points and extensions, and events and listeners. Is
there
> a specific difference when dealing with events and listeners? If I want my
> "view" to fire off certain events, is the concept of events and listeners
> null and void in Eclipse, replaced by the use of extensions and
interfaces?
Basically, extension points and extensions have nothing to do with
events/listeners. You declare places in your plugin where it could be
extended (extension point) and other plugins contribute some functionality
according to the rules you define (extension).
So, extension points and listeners are not mutually exclusive but
complimentary.
Eugene
|
|
|
| Re: Extensions/points and events/listeners, differences? [message #131485 is a reply to message #131289] |
Mon, 05 January 2004 12:11 |
| Eclipse User |
|
|
|
Hi Eugene,
I almost agree with this, only that it seems when an extension point walks
its list of extensions, that is almost the same thing as an event being
fired, where the firing code walks the list of event listeners. The only
difference I see is if the use of the extension point walking the list is
done each time a "button" is pressed for example, or if the first time, the
extension point walks the list, gets a listener class from each and adds it
to some internal list of listeners, then from then on, the events are fired
like usual. Complimentary, possibly but really it seems that it's the same
thing. At some point, you are walking the list of extensions to add them as
listeners, so why even add them. Why not just walk the list of extensions
each time a button is pressed (assuming an extension point is referring to a
button it adds) and call the method of the interface each extension
implements? The ONLY difference I see in this manner is that with Swing,
events would go through the swing event thread, handled when they can be,
where as this way, walking the extensions, is basically sequential and in
the order the extensions are found.
"Eugene Ostroukhov" <eostroukhov@hotmail.com> wrote in message
news:btbe44$91u$1@eclipse.org...
>
> "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> news:bt80fs$blt$1@eclipse.org...
> > I am trying to figure out if there is any special handling through the
> > plugin.xml for a plugin to indicate it fires some user defined event it
> > provides and for other plugins to "tap into" listening for that event
via
> > the plugin.xml file(s) they provide.
>
> I believe, no.
>
> > In general, plugins are lazy created.
> > So if my plugin wants to fire an event that other plugins want to listen
> > for, how is that done? Do I provide an extension point and first create
> all
> > extensions, which each extension code of each plugin wanting to listen
> then
> > adds their listener? Or is there a more "automagic" manner in handling
> such
> > a common practice as this such that the eclipse plugin engine handles
this
> > for me and I simply provide listener classes via plugin.xml extension
> > plugins?
>
> There is no automated way to work with listener. In general, when you
start
> your plugin you should manually walk the extensions and add them as
> listeners (i.e. instantiate classes or lookup initialized instances in
some
> well-defined places, etc.
>
> > Sorry if this is confusing, I am just trying to understand the
correaltion
> > between extension points and extensions, and events and listeners. Is
> there
> > a specific difference when dealing with events and listeners? If I want
my
> > "view" to fire off certain events, is the concept of events and
listeners
> > null and void in Eclipse, replaced by the use of extensions and
> interfaces?
>
> Basically, extension points and extensions have nothing to do with
> events/listeners. You declare places in your plugin where it could be
> extended (extension point) and other plugins contribute some functionality
> according to the rules you define (extension).
> So, extension points and listeners are not mutually exclusive but
> complimentary.
>
> Eugene
>
>
|
|
|
| Re: Extensions/points and events/listeners, differences? [message #131498 is a reply to message #131276] |
Mon, 05 January 2004 12:12 |
| Eclipse User |
|
|
|
When you use API methods of a required plugin, is that through an interface?
OR through a static ref to the plugin class, then making public method
calls? How is this API defined?
"Daniel Megert" <daniel.megert@gmx.net> wrote in message
news:btbdel$892$1@eclipse.org...
> spiderman wrote:
>
> >I am trying to figure out if there is any special handling through the
> >plugin.xml for a plugin to indicate it fires some user defined event it
> >provides and for other plugins to "tap into" listening for that event via
> >the plugin.xml file(s) they provide. In general, plugins are lazy
created.
> >So if my plugin wants to fire an event that other plugins want to listen
> >for, how is that done? Do I provide an extension point and first create
all
> >extensions, which each extension code of each plugin wanting to listen
then
> >adds their listener? Or is there a more "automagic" manner in handling
such
> >a common practice as this such that the eclipse plugin engine handles
this
> >for me and I simply provide listener classes via plugin.xml extension
> >plugins?
> >
> >Sorry if this is confusing, I am just trying to understand the
correaltion
> >between extension points and extensions, and events and listeners. Is
there
> >a specific difference when dealing with events and listeners? If I want
my
> >"view" to fire off certain events, is the concept of events and listeners
> >null and void in Eclipse, replaced by the use of extensions and
interfaces?
> >
> >thanks.
> >
> >
> >
> The plug-in who contains a class that offers to add a listener and fire
> events is declared as a required plug-in and then you can simply use the
> API methods of that class to add the listener. There's nothing to be
> done in XML except declaring the plug-in as required. For you as the
> plug-in writer this means you simply have to provide the corresponding
> API (via Java code).
>
> Dani
>
|
|
|
| Re: Extensions/points and events/listeners, differences? [message #131542 is a reply to message #131485] |
Mon, 05 January 2004 12:57 |
| Eclipse User |
|
|
|
Sorry, had another question on this issue. When you walk the extension list
I assume part of the "api" the extension point expects each extension to
provide is a classname of the listener that implements the listener type for
the event it wants to listen to (assuming an extension point were to define
its API in this way). The problem I see with this, or with ANY ability for
extensions to add event listeners, is that each extension plugin would have
to be created at startup in order to have their listener class instances
added to listen for events. This doesn't promote lazy creation of plugins
very well in my opinion. Is this how it is done? Or is there a way to
"delay" the creation of the plugin and it's listener class for each plugin
that extends the extension point until the event is first fired? Sort of
like a proxy event listener that handles the first event, then creates all
the extension listeners, adds their classes to the list, etc?
"spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
news:btc5qt$6kc$1@eclipse.org...
> Hi Eugene,
>
> I almost agree with this, only that it seems when an extension point walks
> its list of extensions, that is almost the same thing as an event being
> fired, where the firing code walks the list of event listeners. The only
> difference I see is if the use of the extension point walking the list is
> done each time a "button" is pressed for example, or if the first time,
the
> extension point walks the list, gets a listener class from each and adds
it
> to some internal list of listeners, then from then on, the events are
fired
> like usual. Complimentary, possibly but really it seems that it's the same
> thing. At some point, you are walking the list of extensions to add them
as
> listeners, so why even add them. Why not just walk the list of extensions
> each time a button is pressed (assuming an extension point is referring to
a
> button it adds) and call the method of the interface each extension
> implements? The ONLY difference I see in this manner is that with Swing,
> events would go through the swing event thread, handled when they can be,
> where as this way, walking the extensions, is basically sequential and in
> the order the extensions are found.
>
>
> "Eugene Ostroukhov" <eostroukhov@hotmail.com> wrote in message
> news:btbe44$91u$1@eclipse.org...
> >
> > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > news:bt80fs$blt$1@eclipse.org...
> > > I am trying to figure out if there is any special handling through the
> > > plugin.xml for a plugin to indicate it fires some user defined event
it
> > > provides and for other plugins to "tap into" listening for that event
> via
> > > the plugin.xml file(s) they provide.
> >
> > I believe, no.
> >
> > > In general, plugins are lazy created.
> > > So if my plugin wants to fire an event that other plugins want to
listen
> > > for, how is that done? Do I provide an extension point and first
create
> > all
> > > extensions, which each extension code of each plugin wanting to listen
> > then
> > > adds their listener? Or is there a more "automagic" manner in handling
> > such
> > > a common practice as this such that the eclipse plugin engine handles
> this
> > > for me and I simply provide listener classes via plugin.xml extension
> > > plugins?
> >
> > There is no automated way to work with listener. In general, when you
> start
> > your plugin you should manually walk the extensions and add them as
> > listeners (i.e. instantiate classes or lookup initialized instances in
> some
> > well-defined places, etc.
> >
> > > Sorry if this is confusing, I am just trying to understand the
> correaltion
> > > between extension points and extensions, and events and listeners. Is
> > there
> > > a specific difference when dealing with events and listeners? If I
want
> my
> > > "view" to fire off certain events, is the concept of events and
> listeners
> > > null and void in Eclipse, replaced by the use of extensions and
> > interfaces?
> >
> > Basically, extension points and extensions have nothing to do with
> > events/listeners. You declare places in your plugin where it could be
> > extended (extension point) and other plugins contribute some
functionality
> > according to the rules you define (extension).
> > So, extension points and listeners are not mutually exclusive but
> > complimentary.
> >
> > Eugene
> >
> >
>
>
|
|
|
| Re: Extensions/points and events/listeners, differences? [message #131577 is a reply to message #131498] |
Mon, 05 January 2004 13:16 |
| Eclipse User |
|
|
|
Originally posted by: daniel.megert.gmx.net
spiderman wrote:
>When you use API methods of a required plugin, is that through an interface?
>
>
Yes, e.g. org.eclipse.ui.IPartListener but might also be a class, e.g.
org.eclipse.swt.widget.Control.
Dani
>OR through a static ref to the plugin class, then making public method
>calls? How is this API defined?
>
>"Daniel Megert" <daniel.megert@gmx.net> wrote in message
>news:btbdel$892$1@eclipse.org...
>
>
>>spiderman wrote:
>>
>>
>>
>>>I am trying to figure out if there is any special handling through the
>>>plugin.xml for a plugin to indicate it fires some user defined event it
>>>provides and for other plugins to "tap into" listening for that event via
>>>the plugin.xml file(s) they provide. In general, plugins are lazy
>>>
>>>
>created.
>
>
>>>So if my plugin wants to fire an event that other plugins want to listen
>>>for, how is that done? Do I provide an extension point and first create
>>>
>>>
>all
>
>
>>>extensions, which each extension code of each plugin wanting to listen
>>>
>>>
>then
>
>
>>>adds their listener? Or is there a more "automagic" manner in handling
>>>
>>>
>such
>
>
>>>a common practice as this such that the eclipse plugin engine handles
>>>
>>>
>this
>
>
>>>for me and I simply provide listener classes via plugin.xml extension
>>>plugins?
>>>
>>>Sorry if this is confusing, I am just trying to understand the
>>>
>>>
>correaltion
>
>
>>>between extension points and extensions, and events and listeners. Is
>>>
>>>
>there
>
>
>>>a specific difference when dealing with events and listeners? If I want
>>>
>>>
>my
>
>
>>>"view" to fire off certain events, is the concept of events and listeners
>>>null and void in Eclipse, replaced by the use of extensions and
>>>
>>>
>interfaces?
>
>
>>>thanks.
>>>
>>>
>>>
>>>
>>>
>>The plug-in who contains a class that offers to add a listener and fire
>>events is declared as a required plug-in and then you can simply use the
>>API methods of that class to add the listener. There's nothing to be
>>done in XML except declaring the plug-in as required. For you as the
>>plug-in writer this means you simply have to provide the corresponding
>>API (via Java code).
>>
>>Dani
>>
>>
>>
>
>
>
>
|
|
|
| Re: Extensions/points and events/listeners, differences? [message #131703 is a reply to message #131542] |
Tue, 06 January 2004 03:34 |
| Eclipse User |
|
|
|
Originally posted by: eostroukhov.hotmail.com
I'm currently working with Eclipse 2.1.2 so I don't know for sure how
Eclipse 3.0 will work, but Eclipse 2.1.2 activates plugin when you need the
class for it i.e.:
IExtensionPoint extensionPoint =
plugin.getDescriptor().getExtensionPoint("storages"); // Extension
plugins are still inactive
List storageTypes =
new ArrayList(extensionPoint.getExtensions().length);
IExtension[] extensions = extensionPoint.getExtensions(); // Extension
plugins are still inactive
for (int i = 0; i < extensions.length; i++) {
IConfigurationElement[] configurationElements =
extensions[i].getConfigurationElements(); // Extension plugins are
still inactive
for (int j = 0; j < configurationElements.length; j++) {
try {
storageTypes.add(
configurationElements[j].createExecutableExtension(
"storage-type")); // Only this call to createExecutable
extension activates the plugin that supplied the extension.
} catch (CoreException e) {
log.error("Failed to instantiate class", e);
}
}
}
return storageTypes;
So you can activate child plugins only when the first event that should be
fired to listener is triggered. No plugins will be be activated when the
plugin that supplied extension point is activated - you have pretty
fine-grained control over when to activate the "child" plugins. I.e.:
private List listeners = null;
private void fireMyEvent(MyEvent event) {
if (listeners == null) {
initializeListeners();
}
for (Iterator i = listeners.iterator(); i.hasNext(); ) {
((MyListener)i.next).onMyEvent(event);
}
}
private void initializeListeners() {
listeners = new ArrayList(...);
// Walk the extensions and add listeners.
}
In Eclipse 2.1.2 you don't have dynamic plugins so it's enough to check
extensions once.
So I cannot think of more lazy way to activate the child plugins. Or you
just want to avoid activating child plugins at all?
Best regards,
Eugene
"spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
news:btc8gm$9kv$1@eclipse.org...
> Sorry, had another question on this issue. When you walk the extension
list
> I assume part of the "api" the extension point expects each extension to
> provide is a classname of the listener that implements the listener type
for
> the event it wants to listen to (assuming an extension point were to
define
> its API in this way). The problem I see with this, or with ANY ability for
> extensions to add event listeners, is that each extension plugin would
have
> to be created at startup in order to have their listener class instances
> added to listen for events. This doesn't promote lazy creation of plugins
> very well in my opinion. Is this how it is done? Or is there a way to
> "delay" the creation of the plugin and it's listener class for each plugin
> that extends the extension point until the event is first fired? Sort of
> like a proxy event listener that handles the first event, then creates all
> the extension listeners, adds their classes to the list, etc?
|
|
|
| Re: Extensions/points and events/listeners, differences? [message #131763 is a reply to message #131703] |
Tue, 06 January 2004 12:00 |
| Eclipse User |
|
|
|
Very good reply. I figured that is basically how it's done. First, I have to
ask if there is a utility class in Eclipse that does most of this work? It
seems EVERY extension point either has to walk it's list of extensions if
more than one can be called (i.e. an event listener case like you present),
or it has to use a preference to choose a specific extension to use, or in
the case of something like an email filter list of plugins, it make allow
the user to define the order in which they are called, if they are
active/inactive, etc.
Still, it seems pretty laborious to do this for each extension point. I
realize that it's different plugin developers usually writing the extension
points, but the same thing seems to apply in most cases.
Still, it answers my question on how listeners are added. I wasn't sure if
there was an automagic way of handling it, such that you wouldn't have to
walk the extension list, grab a listener class name and create it.
I take it the createExecutableExtension() is only to be used to create an
instance of a class within an extension plugin, correct? Is there any way
for an ExtensionPoint to define an interface AND implement it such that
extension plugins could get a ref to the implementation of the interface
from the extension point, and "control" the extension point. This is sort of
the reverse of how it works now, but I can see where such cases may be
useful. Or, is it better that an extension point define two interfaces. One
is the one extensions implement, the other is an implementation the
extension point implements and passes to each extension so that each
extension can make calls on the passed in implementation the extension point
sends. The only problem I see with this is classloader visibility. Each
extension plugin would have to have access to the extension point
classloader in order to see the class bytecode of the 2nd interface passed
to each extension plugin. Does that make sense? Is that possible now? How
would that be done?
"Eugene Ostroukhov" <eostroukhov@hotmail.com> wrote in message
news:btdrq5$sfe$1@eclipse.org...
> I'm currently working with Eclipse 2.1.2 so I don't know for sure how
> Eclipse 3.0 will work, but Eclipse 2.1.2 activates plugin when you need
the
> class for it i.e.:
>
> IExtensionPoint extensionPoint =
> plugin.getDescriptor().getExtensionPoint("storages"); // Extension
> plugins are still inactive
> List storageTypes =
> new ArrayList(extensionPoint.getExtensions().length);
> IExtension[] extensions = extensionPoint.getExtensions(); // Extension
> plugins are still inactive
> for (int i = 0; i < extensions.length; i++) {
> IConfigurationElement[] configurationElements =
> extensions[i].getConfigurationElements(); // Extension plugins are
> still inactive
> for (int j = 0; j < configurationElements.length; j++) {
> try {
> storageTypes.add(
> configurationElements[j].createExecutableExtension(
> "storage-type")); // Only this call to
createExecutable
> extension activates the plugin that supplied the extension.
> } catch (CoreException e) {
> log.error("Failed to instantiate class", e);
> }
> }
> }
> return storageTypes;
>
> So you can activate child plugins only when the first event that should be
> fired to listener is triggered. No plugins will be be activated when the
> plugin that supplied extension point is activated - you have pretty
> fine-grained control over when to activate the "child" plugins. I.e.:
>
> private List listeners = null;
>
> private void fireMyEvent(MyEvent event) {
> if (listeners == null) {
> initializeListeners();
> }
> for (Iterator i = listeners.iterator(); i.hasNext(); ) {
> ((MyListener)i.next).onMyEvent(event);
> }
> }
>
> private void initializeListeners() {
> listeners = new ArrayList(...);
> // Walk the extensions and add listeners.
> }
>
> In Eclipse 2.1.2 you don't have dynamic plugins so it's enough to check
> extensions once.
> So I cannot think of more lazy way to activate the child plugins. Or you
> just want to avoid activating child plugins at all?
>
> Best regards,
> Eugene
>
>
> "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> news:btc8gm$9kv$1@eclipse.org...
> > Sorry, had another question on this issue. When you walk the extension
> list
> > I assume part of the "api" the extension point expects each extension to
> > provide is a classname of the listener that implements the listener type
> for
> > the event it wants to listen to (assuming an extension point were to
> define
> > its API in this way). The problem I see with this, or with ANY ability
for
> > extensions to add event listeners, is that each extension plugin would
> have
> > to be created at startup in order to have their listener class instances
> > added to listen for events. This doesn't promote lazy creation of
plugins
> > very well in my opinion. Is this how it is done? Or is there a way to
> > "delay" the creation of the plugin and it's listener class for each
plugin
> > that extends the extension point until the event is first fired? Sort of
> > like a proxy event listener that handles the first event, then creates
all
> > the extension listeners, adds their classes to the list, etc?
>
>
|
|
|
| Re: Extensions/points and events/listeners, differences? [message #133284 is a reply to message #131763] |
Mon, 12 January 2004 03:22 |
| Eclipse User |
|
|
|
Originally posted by: eostroukhov.hotmail.com
"spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
news:btephn$1jf$1@eclipse.org...
> Very good reply. I figured that is basically how it's done. First, I have
to
> ask if there is a utility class in Eclipse that does most of this work? It
> seems EVERY extension point either has to walk it's list of extensions if
> more than one can be called (i.e. an event listener case like you
present),
> or it has to use a preference to choose a specific extension to use, or in
> the case of something like an email filter list of plugins, it make allow
> the user to define the order in which they are called, if they are
> active/inactive, etc.
I don't know of such plugin - but it's really easy to create a utility that
will take name of the extension point and class name attribute and will
return collection of the extensions. I haven't found such utility in the
org.eclipse.core.runtime package.
> I take it the createExecutableExtension() is only to be used to create an
> instance of a class within an extension plugin, correct? Is there any way
> for an ExtensionPoint to define an interface AND implement it such that
> extension plugins could get a ref to the implementation of the interface
> from the extension point, and "control" the extension point. This is sort
of
> the reverse of how it works now, but I can see where such cases may be
> useful. Or, is it better that an extension point define two interfaces.
One
> is the one extensions implement, the other is an implementation the
> extension point implements and passes to each extension so that each
> extension can make calls on the passed in implementation the extension
point
> sends. The only problem I see with this is classloader visibility. Each
> extension plugin would have to have access to the extension point
> classloader in order to see the class bytecode of the 2nd interface passed
> to each extension plugin. Does that make sense? Is that possible now? How
> would that be done?
As far as I understood you are asking if the plugin that declares extension
point can also provide some interface, so the reference to its
implementation can be obtained by the extension plugin and some methods are
called - right? Extension plugin (the one that contributes tio the extension
point) must declare dependency on a plugin that declares extension point -
so it has access to all classes that are exported by that plugin. You can
instantiate classes, use static methods, so on - you use a lot of classes
from the eclipse teams' plugins when you write your plugin.
Best regards,
Eugene
|
|
|
Goto Forum:
Current Time: Fri Oct 31 11:34:34 EDT 2025
Powered by FUDForum. Page generated in 0.06285 seconds |
Home