Home » Eclipse Projects » Rich Client Platform (RCP) » adapters extension point(adapters extension point not working)
| adapters extension point [message #530556] |
Fri, 30 April 2010 07:40  |
 Madhu Samuel
Messages: 199
Registered: July 2009 |
Senior Member |
|
|
Folks,
I created an rcp with just 2 views. A table viewer and a properties view.
I used the adapters extension point as follows.
<extension
id="mycompany.adapterfactory.one"
point="org.eclipse.core.runtime.adapters">
<factory
adaptableType="com.mycompany.employee.model.Employee"
class=" com.mycompany.propertiesview.adapters.EmployeePropertiesAdap terFactory ">
<adapter
type="org.eclipse.ui.views.properties.IPropertySource">
</adapter>
</factory>
</extension>
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?
Regards,
Madhu
http://eclipsebible.com
|
|
|
| Re: adapters extension point [message #530801 is a reply to message #530556] |
Sat, 01 May 2010 06:25  |
|
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.
Craig
> Folks,
>
> I created an rcp with just 2 views. A table viewer and a properties
> view.
>
> I used the adapters extension point as follows.
>
> <extension
> id="mycompany.adapterfactory.one"
> point="org.eclipse.core.runtime.adapters">
> <factory
> adaptableType="com.mycompany.employee.model.Employee"
> class="
> com.mycompany.propertiesview.adapters.EmployeePropertiesAdap
> terFactory ">
> <adapter
> type="org.eclipse.ui.views.properties.IPropertySource">
> </adapter>
> </factory>
> </extension>
>
> 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 |
|
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
"actuallyLoad"?
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.
Craig Foote
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
> sparingly.
>
> In your own RCP app, go wild :-)
>
> PW
|
|
| |
| Re: adapters extension point [message #532895 is a reply to message #532723] |
Tue, 11 May 2010 13:27 |
|
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
situation.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=201743
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
degradation.
PW
--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
| |
| Re: adapters extension point [message #532954 is a reply to message #530556] |
Tue, 11 May 2010 16:44 |
|
Yes, thanks Paul. I understand the situation better now and feel much better knowing we aren't totally off base with our solution. Can you clarify for me though the difference between using AdapterManager#getAdapter and #loadAdapter please?
For instance if I have a bundle with an Adapters extension but am not explicitly starting that it (via Startup extension or otherwise), am I correct in thinking neither method will ever return an adapter? Am I correct in thinking that if I did start the bundle that both methods will always return an adapter? If so, what is/are the difference(s)?
Thanks again,
Craig
|
|
| |
| Re: adapters extension point [message #533027 is a reply to message #530556] |
Tue, 11 May 2010 23:24 |
|
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,
Craig
[Updated on: Tue, 11 May 2010 23:45] Report message to a moderator |
|
| | |
| Re: adapters extension point [message #533207 is a reply to message #533168] |
Wed, 12 May 2010 14:51 |
|
That would be great Paul. Is there anything more I can do, vote on the bug or something? I assume with 3.6 in milestones it's too late to get the change in that version and as a new functionality it would not qualify for a 3.6.x, correct?
Craig
|
|
| | | |
Goto Forum:
Current Time: Tue Apr 16 08:49:58 GMT 2024
Powered by FUDForum. Page generated in 0.28380 seconds |
] 
Search
Help
Register
Login
Home
