[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
|
[news.eclipse.tools] Re: Plugin that implements its own interface, how can other plugins use this?
|
Ahh, so there is no built in plugin engine mechanism that will auto handle
these types of dependencies? You simply declare a static type of the plugin
itself or a static method to the plugin to get a handle to it, and because
its a singleton its always the only one in the system, then you call public
methods on it?
"Jared Burns" <jared-eclipse@xxxxxxxxx> wrote in message
news:b2951u$p0b$1@xxxxxxxxxxxxxxxx
> We do this in debug land using a public "factory" that will return objects
> that implement our interfaces. JDIDebugModel is a public class (that is,
> it's defined in a package without the word "internal" in it) that provides
> static methods like createExceptionBreakpoint, createMethodBreakpoint,
etc.
>
> These methods return an implementation of the public interfaces we
provide.
>
> - Jared
>
> Kevin wrote:
> > My example always goes back to a simple plugin like a MenuBar. If I
wrote
> > a plugin that provides and interface AND implements it, so that other
> > plugins can use my plugins implementation, how would other plugins
> > "depend" upon mine and make calls to it? Normally, a plugin provides an
> > extension point via an interface. Other plugins implement that interface
> > and the main plugin calls into that interface to use the "unknown"
> > implementation of plugins implementing the interface. This is quite the
> > reverse. What if I don't want other plugins to implement my interface. I
> > just want to provide a sort of "service" that other plugins can use.
> > Another example might be a "global repository of data", where by my
plugin
> > provides an interface with getAttribute(), setAttribute(),
> > removeAttribute(). My plugin would then implement this interface. Other
> > plugins would use the interface (getting a ref to my implemented plugin
of
> > the interface), so that they could all "share" data using the interface
> > calls since they all would get the same one implementation ref to my
> > plugin.