|adapters extension point [message #530556]
||Fri, 30 April 2010 07:40
| Madhu Samuel
Registered: July 2009
I created an rcp with just 2 views. A table viewer and a properties view.
I used the adapters extension point as follows.
class=" com.mycompany.propertiesview.adapters.EmployeePropertiesAdap terFactory ">
But I think that the adapter factory is not getting registered. The properties view is not getting updated. When the AdapterManager looks for Adapter factories for IPropertySource, it returns null.
Is there any bug related with this extension point?
|Re: adapters extension point [message #532723 is a reply to message #531019]
||Tue, 11 May 2010 02:28
|| Craig Foote
Registered: July 2009
Hmmm, not sure I agree with "Until the user creates the view, no one |
wants to start the core plugin...". We have many cases where we use
menuContributions like "Open with > [some view]" with expressions that
check if the selected item(s) adapts to that view's input type. The user
doesn't normally open the view from Window > Show View but rather uses
the menuContribution. We've found the "adapts" clause of the expression
always returns false unless we use a startup extension in the bundle
declaring the sought "adapters" extension.
As you guessed we have our adapters in bundles separate from the model,
often in separate features. We did this to separate concerns (a model
need not be polluted with other models), and for dependency management.
We build our features independently using P2 and find it easier to build
a given feature if it doesn't include adapters because they have further
dependencies. We're not quite there yet but we'd like to be able to allow
a user to install and uninstall features. To illustrate, if a given
feature_A is removed, all features that depend on it have to be removed -
separating adapters from feature_B's model(s) to feature_A's model(s) out
to a feature of their own, say feature_B-A_adapters, allows the removal
of feature_B-A_adapters while leaving feature_B and any other still-valid
adapters. It makes for a lot of features but they're cheap :)
Also, what's the point of *declaring* factories if they can't be used
without first loading their bundle? The extension registry knows they're
there without loading their bundle so couldn't the AdapterManager start
the plugin when asked? Doesn't the "adapts" expression clause use
#hasAdapter? Couldn't #loadAdapter be overloaded to take a boolean
Sorry if I've rambled but this is beginning to affect our app's
performance and I'm wondering if there's something we're just doing
wrong. I appreciate the help BTW.
On Mon, 03 May 2010 08:10:23 -0400, Paul Webster wrote:
> Craig Foote wrote:
>> On Fri, 30 Apr 2010 13:10:25 +0530, Madhu Samuel wrote: I'm having the
>> same problem that I've fixed by using loadAdapter rather than
>> getAdapter and adding a Startup extension to the plugin with the
>> factory. I'm not happy with the Startup extension though so I'd also
>> like to know the correct solution.
> The adapters are only returned from getAdapter(*) after the plugin has
> been started. Common usecase: Adapters are registered from a core
> plugin that contains the model, and a UI plugin contributes actions and
> a view that contains the model. Until the user creates the view, no one
> wants to start the core plugin and so the adapters aren't returned. Once
> the view is created it will load the model and the adapters are
> available to be returned.
> If the adapters are in a bundle by themselves, then you would need to
> start that bundle in order to get them (since using only the extension
> point will deliberately not load the classes). The startup extension
> is probably OK as well if it is a small library plugin with no UI
> elements. Using loadAdapter instead of getAdapter is what we do when we
> require a more accurate list, but in the IDE/Workbench it is to be used
> In your own RCP app, go wild :-)
|Re: adapters extension point [message #532895 is a reply to message #532723]
||Tue, 11 May 2010 13:27
| Paul Webster
Registered: July 2009
Craig Foote wrote:|
> Hmmm, not sure I agree with "Until the user creates the view, no one
> wants to start the core plugin...".
Mine wasn't a comment on the consensus, it's a policy based on the
common usecase :-) Different products (especially non-IDE RCP products)
will always have usecases that don't need (and don't want) to apply the
lazy loading strategy. But our main "product" is the IDE and that's the
policy we arrived at.
> Also, what's the point of *declaring* factories if they can't be used
> without first loading their bundle?
So that they could be used without incurring heavy startup penalties,
and there's some configurability i.e. especially in your case, you can
start your adapter bundle without incurring heavy UI plugin startup
costs. Your menu items would be more accurate. But there's a history
component here. Adapters used to be programmatic, and starting every
plugin that registers adapters was prohibitive. When the lazy loading
strategy was implemented, adapters were declared instead but to avoid
starting all of the same plugins and incurring the exact same cost (many
plugins moved from programmaticly adding adapters to simply declaring
them), they are not loaded by declarative use unless their plugin has
already been started. If you have an RCP app with 8 plugins plus the
workbench and the bundle activators don't do much, it's not much of a
cost although the framework can now load any classes declared in
extensions that it thinks it needs. For CDT or PDT based on eclipse
classic (with PDE/JDT) it can be noticeable.
That's not to say there's no room for improvement. For example, in core
expressions there's a test element that calls out to a PropertyTester
subclass. The test element supports a forcePluginActivation attribute.
i.e. A user of a property tester can decide "In my case, I'm willing
to incur the startup costs to get 100% accuracy". But the cost for not
understanding what will be started can be prohibitive depending on the
Core Expressions: adapt element should optionally use .getAdaptor(..)
I've also seen requests for adding a forcePluginActivation to the adapt
core expression element ... but I can't find a bug for it.
> Sorry if I've rambled but this is beginning to affect our app's
> performance and I'm wondering if there's something we're just doing
> wrong. I appreciate the help BTW.
Since you can isolate your adapters and force that plugin to start, and
the risk of performance degradation is huge, we just don't do much in
this area. We traded off 100% accuracy for some scalability with lazy
loading + some guidelines. If you separate out your adapters, you can
start that plugin yourself and control how much more accurate it will be
in your case.
I don't think your "doing wrong". I guess it's about gathering enough
information so you can decide 1) to live with the eclipse lazy loading
strategy or 2) activate things eagerly to get accuracy vs startup
|Re: adapters extension point [message #533027 is a reply to message #530556]
||Tue, 11 May 2010 23:24
|| Craig Foote
Registered: July 2009
Ah yes, that makes more sense to me now. As I now recall, we added the "Startup" extension because the "adapts" expression was returning false. So I guess that indicates it does not use #loadAdapter - does it use #getAdapter then? If so, could that somehow be an attribute of the "adapts" element, similar to the request in https://bugs.eclipse.org/bugs/show_bug.cgi?id=201743 for an IAdaptable API call. I understand the need to support legacy code and "IDE first" but if it was possible to make a simple configuration setting and remove the confusing need for a "Startup" extension, i.e. to make the expression use #loadAdapter, I think we have a couple consumers right here Would that even be possible? I guess that's the gist of the other bug you mentioned though. If you can find it, I'd like to vote for it!|
As always, your help is greatly appreciated,
[Updated on: Tue, 11 May 2010 23:45]
Report message to a moderator
Powered by FUDForum
. Page generated in 0.02099 seconds