Bugzilla – Full Text Bug Listing
| Summary: | Exposure of workbench part controls to clients | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | amehrega | ||||
| Component: | UI | Assignee: | Kim Horne <eclipse> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | bokowski, eclipse, hkyleung, Kevin_Haaland, mfaraj, michaelvanmeekeren, sluiman | ||||
| Version: | 3.2 | ||||||
| Target Milestone: | 3.2 RC1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 126580 | ||||||
| Attachments: |
|
||||||
|
Description
amehrega
You can already do this for your parts. Workbench parts implement IAdaptable. You could subclass getAdapter() return your part control when asked for the Control adapter. As a rule we don't want to be adding testing methods to commonly used public interfaces. Yes, that would be possible for as long as I have access to the workbench part code and I could enforce clients to use the version that I would like them to use. The reason why I need a public API is because testing tools are expected to work with any existing view/editor within the Eclipse platform (e.g. such as the package explorer). I had a short chat with Kim, and they are unwilling for exposing something like this (seeing it as something dangerous, which I can understand). Harm, We can either swallow this and go with the internal API usage or we can build a better argument that convinces the Eclipse folks. Well, the default implementation of getAdapter() on WorkbenchPart delegates to the platform adapter manager. You don't need direct access to the parts - you could could supply an adapter factory that uses the internal API for parts that don't explicitly supply an adapter for Control. Thanks for the suggestion Kim but this still doesn't avoid the original problem for which I opened this defect for (i.e. avoiding internal APIs all together). Quite right, sorry. Coffee isn't fully digested yet. I spoke with Kevin Haaland about this and he was okay with re-opening this enhancement with the following changes: May be there is another approach that could be implemented instead of the getControl() accessor which I understand has unpleasant side effects that would enable TPTP to get a testing interface for parts. (e.g. ITestableWorkbenchPart) It will be great if the adapter that Kim suggested below was provided internally. The adapter would be implemented for views and editors and would be used as follows: IWorkbenchPart view = [some view] ITestableWorkbenchPart testableView = (ITestableWorkbenchPart) view.getAdapter (ITestableWorkbenchPart.class); Control control = testableView.getControl(); The purpose of the new API (i.e. ITestableWorkbenchPart) would be to verify the state that a particular editor or view is in. Many automated GUI recorder tools include verification mechanisms that allow them to extract specific controls from a shell to be able to verify that their values equal to expected results. For example, to verify the presence of a text box that displays an error in a view, the recorder will need to: 1) Extract the controls of the view (this is where the new API will be required) 2) Walk through the controls in (1) and find the desired text box 3) Assert that its value is equaled to the expected value specified by the user. Without the presence of a public API that does step (1), the verification mechanism will have to resort to internal APIs. Would it be acceptable if we provided this functionality in a separately downloaded workbench fragment (that we would support, of course)? I got a thumbs up from Harm Sluiman about providing this as a separate package fragment. If you prefer you can host it in TPTP's CVS for as long as it is maintained by the Eclipse developers. Created attachment 27610 [details]
Candidate plugin
Provided is a plugin that provides an adapter on the part SITE (not the part)
for IWorkbenchPartTestable. The source for the plugin is include.
Example usage:
ViewPart partToTest = ...;
IWorkbenchPartTestable testable =
(IWorkbenchPartTestable)partToTest.getSite().getAdapter(IWorkbenchPartTestable.class);
Composite partComposite = testable.getControl();
The control returned by getControl() will always be the composite passed to
createView/EditorPart();
We've yet to iron out where this plugin will live in the eclipse ecosystem.
I should also mention that this required a small change to PartSite which I've checked into HEAD. The attached plugin won't work until next weeks integration build unless you want to brave a nightly build or play with what's in HEAD.. Kim, Can we please finalize this defect and determine where the plug-in will be hosted? I have a defect that's blocking the release of TPTP because of the internal APIs that I'm forced to use. Maybe we'll be better off if we can provide this as part of the platform (marked as a provisional API) as opposed to hosting it as a separate download. The plug-in only has 3 classes and it seems like an overkill to create a completely separate plug-in. Hosting it as a separate download will cause confusion amongst users and developers (for maintenance and configuration management reasons). I also noticed that the plug-in never registers its adapter factory with the platform’s adapter manager. I created a plug-in activator class and added the following to the ‘start’ method of the plug-in: Platform.getAdapterManager().registerAdapters(new TestableAdapterFactory(), IWorkbenchPartSite.class); Any how, TPTP requires this to be resolved as soon as possible. I'll appreciate your quick response. Everyone who can give me answers regarding this issue is currently out of town. I wouldn't expect that this would be resolved before the API freeze next week. I've talked with MvM and neither of us are comfortable with the idea of putting this into the SDK release. We don't have enough time to fully consider the implications and today is the last day before the API freeze. We're willing to host the plug-in on the Platform-UI update site and maintain the source code, however. We'd also be willing to hand it over to you to include in your builds which might make it easier for you to manage the dependency problem. In either case we'd be willing to make it a friend of the org.eclipse.ui.internal package in org.eclipse.ui.workbench to clean up plug-in boundary issues. (Also, you shouldn't have had to add that registration to the bundle activator - the org.eclipse.core.runtime.adapter extension in the plug-in XML should've been sufficient. You might need to activate the bundle, however, because as I understand it the adapter mechanism is lazy under certain circumstances). If this is sufficient for your immediate needs we should plan on talking after 3.2 ships to discuss this and whatever other requirements you might have with regard to testing frameworks within the workbench. Thanks Kim for your quick response. For now we can have the plugin hosted on Eclipse's CVS (under /cvsroot/eclipse). Hubert (who does TPTP's builds) has agreed to download the plugin from your CVS using an anonymous account and build it as part of TPTP's build. At least this way, we'll be able to keep the user unaware of the extra Eclipse plugin needed. For Hubert to build the plug-in successfully, he needs to also have a *feature* included with the plug-in. Please include both a feature and the plug-in under your CVS. I've checked the source for the plug-in and accompanying feature into CVS. they may be found at dev.eclipse.org/cvsroot/eclipse/platform-ui-home/testing/org.eclipse.ui.testing dev.eclipse.org/cvsroot/eclipse/platform-ui-home/testing/org.eclipse.ui.testing-feature Please let me know if this is okay. The plug-in is working fine. Thanks Kim for following upon this. You can go ahead with closing this enhancement Will verify at our end for RC1. Finally marking as verified. My bad. |