Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 318937

Summary:	QVTo Metamodel Explorer View: show the plugin in the property view that registers the selected metamodel
Product:	[Modeling] QVTo	Reporter:	Nicolas Rouquette <nicolas.f.rouquette>
Component:	UI	Assignee:	mmt-atl.web-inbox <mmt-atl.web-inbox>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	P3	CC:	nicolas.f.rouquette, serg.boyko2011
Version:	unspecified
Target Milestone:	---
Hardware:	Macintosh
OS:	Mac OS X
Whiteboard:

Description Nicolas Rouquette

2010-07-05 15:08:33 EDT

The MetamodelExplorer view is really very useful for developing QVT transformations; however, sometimes I need to find more information about a given metamodel.
For example, metamodel-specific utilities, helpers, edit/editors, etc... In other words, where is the plugin that registers a particular metamodel and may provide additional metamodel-specific capabilities?

To answer this question, it would be nice if the metamodel explorer view could show the defining plugin of a selected metamodel.
Since the MetamodelExplorer defines a tree browser -- org.eclipse.m2m.internal.qvt.oml.common.ui.views.MetamodelBrowser -- and a custom property sheet (see below), it seems that it would be easy to add an extra field in the custom property sheet to show the defining plugin.

org.eclipse.m2m.internal.qvt.oml.common.ui.views.MetamodelBrowser.getAdapter(Class)
org.eclipse.m2m.internal.qvt.oml.common.ui.views.MetamodelBrowser.getPropertySheetPage()

Unfortunately, the idiom for Eclipse property sheet involves a great deal of indirection, inversion of control; i.e., idioms that really obfuscate the relationship between the code and the functionality it provides.

If someone can point me to where the magic takes place, I could try to develop a patch to provide this useful capability.

Comment 1 Nicolas Rouquette

2010-07-05 15:12:37 EDT

This was incorrectly assigned to ATL, it should be assigned to QVTO UI.

Comment 2 Sergey Boyko

2010-07-15 05:08:14 EDT

I can suggest to provide special item provider adapter factory (something similar to EcoreItemProviderAdapterFactory class so that it supports IItemPropertySource type). 
In org.eclipse.m2m.internal.qvt.oml.common.ui.views.MetamodelBrowser.getPropertySheetPage() method you can add your adapter factory like:
  ((ComposedAdapterFactory) provider.getAdapterFactory()).insertAdapterFactory(myAdapterFactory);

It would be reasonable if such adapter factory will delegate collecting of properties to some registry of applicable adapters (similar to ComposedAdapterFactory(Descriptor.Registry adapterFactoryDescriptorRegistry)).

Same idea would be useful for metamodel explorer context menu extensions.

Comment 3 Nicolas Rouquette

2010-07-16 23:25:56 EDT

Except for the registration of applicable adapters, are you talking about an approach similar to the one used in org.eclipse.uml2.uml.editor.presentation.UMLEditor.getPropertySheetPage() where org.eclipse.uml2.uml.editor.presentation.UMLEditor.UMLPropertySource.getPropertyDescriptors() has special logic to create additional IPropertyDescriptor based on stereotype applications?

It seems to me that what you are suggesting is a combination of the UMLEditor's UMLAdapterFactoryContentProvider / UMLPropertySource / UMLPropertyDescriptor but with the difference that the logic for adding additional IPropertyDescriptors for applied stereotypes would be done in an extension-defined factory for IItemPropertyDescriptor.

It seems to me that this the kind of UI customization that the new EMF Extended Editing Framework (EEF) should make easier to do than building the above by copying & adapting the mechanisms from the UMLEditor. However, this would require adding a dependency to EEF; I doubt that this would be reasonable to do just to solve this problem so the copy&own strategy may still be the most expedient way for now.