| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <title>Eclipse 3.0 adapter issues</title> |
| <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css"> |
| </head> |
| <body text="#000000" bgcolor="#FFFFFF"> |
| |
| <h1>Eclipse 3.0 adapter issues</h1> |
| <font size="-1">Last modified: February 16, 2004</font> |
| <p> |
| This document outlines proposed changes in the 3.0 timeframe to the |
| <tt>IAdapterManager</tt> infrastructure. Related bug reports contain |
| much of the rationale and discussion: |
| </p> |
| <ul> |
| <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=32498">bug 32498 - Support to contribute adapter factory via XML</a></li> |
| <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=32436">bug 32436 - Using adapters to filter UI selections without loading plugins</a></li> |
| <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=30577">bug 30577 - Actions should check for IAdaptable#getAdapter(IJavaElement.class)</a></li> |
| <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=36968">bug 36968 - [Plan Item] Improve action contributions</a></li> |
| <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37937">bug 37937 - [plan item] Support Java references outside Java code</a></li> |
| <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=29809">bug 29809 - Rename/Delete Action hooks [refactoring]</a></li> |
| <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=29809">bug 29809 - Rename/Delete Action hooks [refactoring]</a></li> |
| <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=29809">bug 29809 - Rename/Delete Action hooks [refactoring]</a></li> |
| </ul> |
| <h3>Current limitations</h3> |
| <ul> |
| <li>Nothing is known about an adapter factory until the plugin that provides the |
| adapter is loaded. This makes it difficult to calculate if an action contribution |
| or refactoring participant may potentially be applicable for a given selection until |
| it is executed.</li> |
| <li>The current API only supports returning a single adapter for a given adaptable |
| type. For example, only one factory is allowed to adapt IFile to IPropertySource. |
| In some contexts, it is appropriate to obtain all possible adapters on a type. Several |
| plug-ins may want to supply an IPropertySource or an IActionFilter for IFile. |
| </li> |
| </ul> |
| <h3>Proposed solution</h3> |
| <p> |
| Add the following three new methods to IAdapterManager:<br> |
| <pre> |
| public boolean hasAdapter(Object adaptable, String adapterTypeName); |
| public Object getAdapter(Object adaptable, String adapterTypeName); |
| public Object[] getAdapters(Object adaptable, String adapterTypeName); |
| </pre> |
| </p> |
| <p> |
| <tt>getAdapter</tt> returns the first non-null adapter found as it does today (transitive |
| search of superclasses and then super-interfaces). <tt>getAdapters</tt> returns all adapters |
| for all superclasses and interfaces of the supplied object. Only factories belonging |
| to loaded plug-ins will be consulted by the <tt>getAdapter*</tt> methods. <tt>hasAdapter</tt> consults |
| both loaded and unloaded factories. |
| </p> |
| <p> |
| A new "adapters" extension in the runtime plug-in will specify the name of the factory |
| class, removing the need for plug-ins to explicitly register their adapters on startup |
| (they would be lazily registered on the first lookup on that factory after the plug-in is loaded): |
| <pre> |
| <extension point="org.eclipse.core.runtime.adapters"> |
| <factory |
| class="org.eclipse.jdt.internal.ui.JavaElementAdapterFactory" |
| adaptableType="org.eclipse.jdt.core.IJavaElement"> |
| <adapter class="org.eclipse.core.resources.IFile"> |
| <adapter class="org.eclipse.ui.views.IPropertySource"> |
| <adapter class="org.eclipse.ui.model.IWorkbenchAdapter"> |
| ... |
| </factory> |
| </extension> |
| </pre> |
| </p> |
| <p> |
| This extension point specifies a factory that adapts IJavaElement to IFile, IPropertySource, etc. |
| Of course, for backwards compatibility we will continue to support adapters |
| registered manually that do no have associated markup. |
| </p> |
| |
| |
| |
| |
| |
| |
| |
| </body> |
| </html> |
