Community
Participate
Working Groups
Version: 3.3.0 Build id: I20070621-1340 The adapt element of the expression mechanism only adapts using the AdapterManager. This is first of all not documented for the adapt element, but it would be better to allow the adaption to optionally be handled via the IAdaptable interface. The choice can be specified in a new attribute of the adapt element as in the following example. (The attribute name is not good :-/)) <extension point="org.eclipse.ui.handlers"> <handler class="....MailContactHandler" commandId="....newmailforcontact"> <enabledWhen> <with variable="selection"> <iterate ifEmpty="false" operator="or"> <adapt type="....data.IContact"> useGetAdapter="true"> <<<<<<<<<<<<<<================ <test forcePluginActivation="true" property="....datamodel.hasMail"> </test> </adapt> </iterate> </with> </enabledWhen> </handler> </extension> Alternatively, the adaption element of in org.eclipse.core.expressions/schema/expressionLanguage.exsd should be properly documented: This element is used to adapt the object in focus to the type specified by the attribute type. The expression returns not loaded if either the adapter or the type referenced isn't loaded yet. It throws a ExpressionException during evaluation if the type name doesn't exist at all. The children of an adapt expression are combined using the and operator. Note that the adaption is solely handled via the AdapterManager and not via the IAdaptable interface. This means all relevant adaption must be declared via the org.eclipse.core.runtime.adapters extension point
I suspect this has to do with the fact that org.eclipse.core.expressions cannot load the adapt-to type, and so cannot use the IAdapatable interface. We'll have to document this in the extension point description. PW
Paul, Do you have any description as to why this is the case. I cannot see why it should be a problem, as you can ask for the adapt-to class in the context of the bundle with the plugin.xml. I'll see if I can make the change and get it to work :-) -- unless of cause you have a description to the contrary.
(In reply to comment #2) > Paul, > > Do you have any description as to why this is the case. I cannot see why it > should be a problem, as you can ask for the adapt-to class in the context of > the bundle with the plugin.xml. I'll see if I can make the change and get it to > work :-) -- unless of cause you have a description to the contrary. > The expression itself provides a string for core.expressions to work with. Even going to the core.expressions bundle won't allow it to load, say org.eclipse.core.resources.IResources so that it can be supplied to IAdaptable#getAdapter(Class). There might be some hack around that but I'm not sure whether it would be acceptable. You could try asking the classloader that loaded the receiver class ... PW
Created attachment 97898 [details] Patch with proposed fix.
Created attachment 97899 [details] Unit test for the feature.
It may not be a perfect solution, but I think this patch would address the most common use case, where the adaptee creates an instance of the adapter directly and returns it from IAdaptable.getAdapter(). BTW, bug 184046 and bug 208336 appear to be duplicates of this request.
*** Bug 184046 has been marked as a duplicate of this bug. ***
*** Bug 208336 has been marked as a duplicate of this bug. ***
It looks to me like the fix will do the trick. But... why doesn't the AdapterManager do this by default? Doesn't it really belong there?
(In reply to comment #9) > It looks to me like the fix will do the trick. > > But... why doesn't the AdapterManager do this by default? Doesn't it really > belong there? Because IAdapterManager was designed to back IAdaptables to allow the types they support to be extended declaratively or programmatically. javadoc: * ... All adaptable objects (that is, objects that implement the <code>IAdaptable</code> * interface) funnel <code>IAdaptable.getAdapter</code> invocations to their * adapter manager's <code>IAdapterManger.getAdapter</code> method... PW
Updated as per http://wiki.eclipse.org/Platform_UI/Bug_Triage PW
*** Bug 366573 has been marked as a duplicate of this bug. ***
Pawel, are you still interested in this? PW
(In reply to comment #13) > Pawel, are you still interested in this? > > PW I don't have any open bugs that depend on this, so I think we found workarounds as needed. But it would be a nice feature to have.
Paul, can we take this one off of the 4.2 list and triage it for a look in 4.3 ?
(In reply to comment #15) > Paul, can we take this one off of the 4.2 list and triage it for a look in 4.3 > ? Yes, I think we'll have to move this off again, sorry about that. PW
Released as http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=68d64830f5798cba21a7f0f14abea3a72df91a59 Thanks Pawel. PW
Thank You :-)
