Summary: | Any chance of an IWorkbenchAdapter ;-) | ||||||
---|---|---|---|---|---|---|---|
Product: | [WebTools] WTP Source Editing | Reporter: | Doug <doug.satchwell> | ||||
Component: | wst.sse | Assignee: | Nick Sandonato <nsand.dev> | ||||
Status: | NEW --- | QA Contact: | Nick Sandonato <nsand.dev> | ||||
Severity: | enhancement | ||||||
Priority: | P3 | CC: | david_williams, d_a_carver | ||||
Version: | unspecified | Keywords: | helpwanted | ||||
Target Milestone: | Future | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | contributed | ||||||
Attachments: |
|
Description
Doug
2008-02-04 16:34:12 EST
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. |