Bugzilla – Full Text Bug Listing
| Summary: | Article on Adapters | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | Wayne Beaton <wayne.beaton> | ||||
| Component: | Articles | Assignee: | community.articles-inbox <community.articles-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | jonb, karsten.thoms, levente.l.borbely, michalsova, sanjay.t.sharma, schmatzler.jona, udo.walker | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Wayne Beaton
Working draft is committed in CVS. :pserver:anonymous@dev.eclipse.org:/cvsroot/org.eclipse www/articles/Article-Adapters Can be viewed online: http://www.eclipse.org/articles/article.php?file=Article-Adapters/index.html Article is not accessible from /resources or /articles landing pages at this point. Created attachment 104921 [details]
mylyn/context/zip
I'm rather new to RCP, so please forgive my ignorance.... 1) Evidently, IPropertySource did not come ready out of the box for plug-in development. I added... import org.eclipse.ui.views.properties.IPropertySource; ...to my code and then told eclipse to import it. 2) Following the code example I created a TableViewer and then tried to set its content and label provider with "new ViewContentProvider()" and "new ViewLabelProvider()" as directed. For the content provider, Eclipse complains... Discouraged access: The type ViewContentProvider is not accessible due to restriction on required library C:\Documents and Settings\jonb\workspace\MAPP3D-gui-rcp-eclipse\plugins\org.eclipse.ui.workbench_3.4.0.I20080606-1300.jar ....and for the label provider, the constructor wants arguments (IWorkbenchWindow and dimmed forground color). Any suggestions as to workarounds? (In reply to comment #3) > I'm rather new to RCP, so please forgive my ignorance.... > > 1) > Evidently, IPropertySource did not come ready out of the box for plug-in > development. I added... > > import org.eclipse.ui.views.properties.IPropertySource; > > ...to my code and then told eclipse to import it. IPropertySource is part of the org.eclipse.ui.views plug-in. Add this plug-in to your plug-in's "Required Bundles". > 2) > Following the code example I created a TableViewer and then tried to set its > content and label provider with "new ViewContentProvider()" and "new > ViewLabelProvider()" as directed. For the content provider, Eclipse > complains... > > Discouraged access: The type ViewContentProvider is not accessible due to > restriction on required library C:\Documents and > Settings\jonb\workspace\MAPP3D-gui-rcp-eclipse\plugins\org.eclipse.ui.workbench_3.4.0.I20080606-1300.jar > > ....and for the label provider, the constructor wants arguments > (IWorkbenchWindow and dimmed forground color). > > Any suggestions as to workarounds? > Did you look at the example code? The code in the article only shows a fragment of what's required. The example code is complete (albeit simple). The ViewContentProvider and ViewLabelProvider are inner classes in the example. You have to define your own providers. Does the example code help? I found and included the plugin. I found the code and copied a bit of it, but that wasn't enough for what I was doing, which is to create a custom table view that could show objects in rows and their properties in columns. It seems as though tree view support is good out of the box, but table view support needs a lot of help to get something that looks like a table to appear. (In reply to comment #5) > I found and included the plugin. I found the code and copied a bit of it, but > that wasn't enough for what I was doing, which is to create a custom table view > that could show objects in rows and their properties in columns. It seems as > though tree view support is good out of the box, but table view support needs a > lot of help to get something that looks like a table to appear. > That may be true. However, I'm quite confident that it's not really an issue with this article I suggest that you move any discussion concerning the TableViewer to the newsgroups (try news://news.eclipse.org/eclipse.platform). Since the article has been published, I'm marking this bug as FIXED. Small syntax error (missing brackets) in paragraph "Decoupling with Adapters"
public Object getAdapter(Class adapter) {
return Platform.getAdapterManager.getAdapter(this, adapter);
}
should be:
public Object getAdapter(Class adapter) {
return Platform.getAdapterManager().getAdapter(this, adapter);
}
Fixed. Thanks. Hi guys, from Wayne´s article it seems adapters are great solution , but from my experience it can be the road to hell. Imagine some complicated system where dependencies between objects are defined only by adapters.Getting the object you want can take lots of time, you will have to debug, go through all plugin.xml files, the adapters defined in xml are sometimes not loaded correctly, because the plugin was not loaded, xml is not checked by the compilator, so if you change your system, it is easy to forget to change some xml file, because there will be no error shown... The adapters can produce unreadable code, which is hard to maintain.If you use emf adapters, they can also cause memory leaks, if you don´t remove them. Try to avoid adapters,use interfaces instead. (In reply to comment #9) > Hi guys, > from Wayne´s article it seems adapters are great solution , but from my > experience it can be the road to hell. Imagine some complicated system where > dependencies between objects are defined only by adapters.Getting the object > you want can take lots of time, you will have to debug, go through all > plugin.xml files, the adapters defined in xml are sometimes not loaded > correctly, because the plugin was not loaded, xml is not checked by the > compilator, so if you change your system, it is easy to forget to change some > xml file, because there will be no error shown... The adapters can produce > unreadable code, which is hard to maintain.If you use emf adapters, they can > also cause memory leaks, if you don´t remove them. Try to avoid adapters,use > interfaces instead. > IMHO, if you define a system based entirely on adapters, you're looking for trouble. There are cases where adaptors are the best solution. Use them in those cases. In an ideal world, you would use interfaces to connect everything. Unfortunately, in a loosely couple system, this is not always possible, so it's good to have adapters for those cases where you need them. The example at the end of the article with the image viewer that shows an image for the selection is a good example of this. I don't necessarily know what kind of thing the selected object is, but I still want to get an image from it. You couldn't implement this in a generic way without something like adapters. (In reply to comment #10) > (In reply to comment #9) > > Hi guys, > > from Wayne´s article it seems adapters are great solution , but from my > > experience it can be the road to hell. Imagine some complicated system where > > dependencies between objects are defined only by adapters.Getting the object > > you want can take lots of time, you will have to debug, go through all > > plugin.xml files, the adapters defined in xml are sometimes not loaded > > correctly, because the plugin was not loaded, xml is not checked by the > > compilator, so if you change your system, it is easy to forget to change some > > xml file, because there will be no error shown... The adapters can produce > > unreadable code, which is hard to maintain.If you use emf adapters, they can > > also cause memory leaks, if you don´t remove them. Try to avoid adapters,use > > interfaces instead. > > > IMHO, if you define a system based entirely on adapters, you're looking for > trouble. There are cases where adaptors are the best solution. Use them in > those cases. In an ideal world, you would use interfaces to connect everything. > Unfortunately, in a loosely couple system, this is not always possible, so it's > good to have adapters for those cases where you need them. The example at the > end of the article with the image viewer that shows an image for the selection > is a good example of this. I don't necessarily know what kind of thing the > selected object is, but I still want to get an image from it. You couldn't > implement this in a generic way without something like adapters. Thanks for response Wayne, I agree almost fully. But to the example, I would rather let all my objects, for which I want get an image implement some interface with getImage method and then I would just check if the selected object is instance of it. Adapters are very flexible, but the price for using them can be high. I also use adapters, but it is only because I´m convenient, I would not recommend them to anybody. (In reply to comment #11) > Thanks for response Wayne, > I agree almost fully. But to the example, I would rather let all my objects, > for which I want get an image implement some interface with getImage method and > then I would just check if the selected object is instance of it. Adapters are > very flexible, but the price for using them can be high. I also use adapters, > but it is only because I´m convenient, I would not recommend them to anybody. > Except that the File class realistically can't be changed to implement some new interface every time you want to do something different with it. (In reply to comment #12) > (In reply to comment #11) > > Thanks for response Wayne, > > I agree almost fully. But to the example, I would rather let all my objects, > > for which I want get an image implement some interface with getImage method and > > then I would just check if the selected object is instance of it. Adapters are > > very flexible, but the price for using them can be high. I also use adapters, > > but it is only because I´m convenient, I would not recommend them to anybody. > > > Except that the File class realistically can't be changed to implement some new > interface every time you want to do something different with it. You´re right, in some cases it is the only way. If you implement for example a only "one purpose" view(unlike PropertySheet),you can depend on the objects directly. It is not a flexible solution, but your code is more understandable. I just wanted to warn against using adapters for everything, I worked on such project some time ago and it wasn´t big fun. Thanks for your articles and answers Hi Wayne, Thanks for this nice article on adapters. I would like to ask, if I want to use an eclipse view or a third party view inside my RCP application, how do I find out what interfaces do these views expect by my application objects (directly or indirectly via adapters) when they are selected ? Would be really nice if you added to this article some additional examples of standard eclipse views and the interfaces they expect. Best regards, Levente Hi there, The link to the ImageViewer sample seems to be broken; you might want to update it to the working link which is http://www.eclipse.org/evangelism/samples/imageviewer/ Cheers, sanjayts On Eclipse API 4 is the usage of the adapter factory extension still the correct way? Or should I use a different API, e.g. OSGi-Services? (In reply to Udo Walker from comment #16) > On Eclipse API 4 is the usage of the adapter factory extension still the > correct way? Or should I use a different API, e.g. OSGi-Services? You should connect directly with the development team via the project forum: http://www.eclipse.org/forums/eclipse.platform Hello, I am currently working with Eclipse 4.9 and have been researching some informations on adapters. I have found this (https://www.eclipse.org/articles/article.php?file=Article-Adapters/index.html) article. It says it is up to date for the releases 3.2, 3.3 and 3.4. My question is : is it still up to date for the release 4.9 or is it deprecated. (In reply to Jean Walter from comment #18) > Hello, > I am currently working with Eclipse 4.9 and have been researching some > informations on adapters. I have found this > (https://www.eclipse.org/articles/article.php?file=Article-Adapters/index. > html) article. It says it is up to date for the releases 3.2, 3.3 and 3.4. > My question is : is it still up to date for the release 4.9 or is it > deprecated. The Adapters framework has had some updates since this article was written (e.g. Java 5 support for generics). However, AFAIK the principles described in the article still apply and the examples still work. |