Community
Participate
Working Groups
In the XSL incubator, we have some code that is similar to that for the XML outline - i.e. content and label providers that cast nodes to INodeNotifier's and then get IJFaceNodeAdapter adapters from this. The problem is that these interfaces are internal, provisional ones. In fact, the full list of internal SSE interfaces used for content and label providers is: org.eclipse.wst.sse.core.internal.provisional.INodeAdapter; org.eclipse.wst.sse.core.internal.provisional.INodeNotifier; org.eclipse.wst.sse.ui.internal.contentoutline.IJFaceNodeAdapter; org.eclipse.wst.sse.core.internal.provisional.INodeAdapter; org.eclipse.wst.sse.core.internal.provisional.INodeNotifier; org.eclipse.wst.sse.ui.internal.contentoutline.IJFaceNodeAdapter; I was wondering if there was not a better way to do this? Many objects (IResource's etc.) simply implement IAdaptable, and then provide an IWorkbenchAdapter adapter for use in content and label providers. This makes writing content and label providers a cinch - you can simply use the standard WorkbenchContentProvider and label provider without knowing anything of the internals of the model. If SSE nodes had this ability, then we wouldn't need to import any of the above provisional interfaces. It would also have the added beneift of making future development efforts that much easier for those who want to make use of SSE and XML plugins!
Whoops - cut + paste accident above; ignore the repeats!
That's actually a very cool idea, I just don't know if we'll have time to do it in this release.
FYI, we did think to do this for IStructuredModel, and IStructuredDocument. But not at a lower level. In fact ... I wonder ... if that would suffice? Once you got your workbench adapter for the model, you could do things with it using a method by passing in the Node. Well, maybe not as good, but some care may be needed if put on small objects such as INodes ... there might end up being quite a few instances made? Just thinking "outloud".
If I remember right, you register an adapter with a class, and then just one instance of the adapter is created per class (not per object!). You can register it via an extension point, and the target class just needs to extend PlatformObject. The singleton adapter is then re-used for all instances of the class. Even better, the single instance of the adapter is only created on demand i.e. with the first request to use it. So, I think it should be OK but it is worth checking.
Created attachment 111615 [details] Patch for changes Some relatively minor changes that can be used to make this work: - make AbstractNotifier extend PlatformObject - a new NodeNotifierWorkbenchAdapterFactory class registered with the org.eclipse.runtime.adapters extension point - a new NodeListWorkbenchAdapter class that wraps a NodeList (this one is entirely optional, but handy as it would commonly be re-used by other plugins. No problem to leave it out though.) With this in place, when creating a TreeViewer, all you need is: tv.setContentProvider(new BaseWorkbenchContentProvider()); tv.setLabelProvider(new WorkbenchLabelProvider()); and then: tv.setInput(document) or tv.setInput(new NodeListWorkbenchAdapter(myNodeList)); The advantage is that there are no dependencies on internal SSE code.
> The advantage is that there are no dependencies on internal SSE code. In general this seems like a good idea .... but, there is API being added right? I know sometimes people "get around" declaring API by using adapters, but that's not a very good practice .... then there's just an undocumented dependency where something will stop working, if the underlying code was removed, or made inaccessible. I'm not saying that's the case here, but would appreciate this being documented and handled as API (and ... it's probably obvious to you all ... just not to me :)
(In reply to comment #5) > Created an attachment (id=111615) [details] > Patch for changes > > Some relatively minor changes that can be used to make this work: > > - make AbstractNotifier extend PlatformObject That first step is a doozy, and would take us to a messier API. It would introduce a getAdapter() method returning Object alongside the existing getAdapterFor() method that returns INodeAdapter.
