Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Compare » Custom content merge viewer(Is accessing internal classes the correct approach?)
Custom content merge viewer [message #1850532] Mon, 07 March 2022 18:09 Go to next message
Philip Alldredge is currently offline Philip AlldredgeFriend
Messages: 20
Registered: February 2013
Junior Member
I am investigating implementing a custom content merge viewer. I have a couple of questions after looking at TreeContentMergeViewer,TreeContentMergeViewerContentProvider, AbstractTreeContentMergeViewer, and EMFCompareContentMergeViewer.

- It appears that it will be necessary to use AccessorAdapter or other internal classes. Is this the expected approach?
- Could my content merge viewer extend Viewer or should it extend EMFCompareContentMergeViewer?
Re: Custom content merge viewer [message #1850680 is a reply to message #1850532] Mon, 14 March 2022 08:10 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1902
Registered: July 2009
Senior Member
Hello Philip,

- I don't think you will have to use AccessorAdapter as this is more of an internal of EMF Compare, but you will likely have to check the ICompareAccessor and subclasses of IStructuralFeatureAccessor as these are how we link the Structure Merge Viewers (SMV, top panel of the compare editor) and the Content Merge Viewer (CMV, bottom panel that shows the trees/properties/...). However, please let us know if some classes are marked as internal but required for sub-classes like the one you are trying to implement as this might be an oversight on our end and we can open APIs as needed.
- The CMV have to implement org.eclipse.compare.contentmergeviewer.ContentMergeViewer at the very least, this is how Eclipse Compare defines CMVs and accepts them through its extension point (org.eclipse.compare.contentMergeViewers). You can take a look at the corresponding plugin.xml to see how we contribute to this extension for our viewers.

Laurent Goubet
Obeo
Re: Custom content merge viewer [message #1850928 is a reply to message #1850680] Tue, 22 March 2022 15:00 Go to previous messageGo to next message
Philip Alldredge is currently offline Philip AlldredgeFriend
Messages: 20
Registered: February 2013
Junior Member
Thanks for the information. I haven't found a way to get the ICompareAccessor without using AccessorAdapter. The input to the CMV appears to be an "ICompareInput". Using that, I can get an ITypedElement for the left and right sides. However the information provided by that interface is limited(name, image, and type). The actual object is an AccessorAdapter and I can get the ICompareAccessor from it by casting. Is there another way of doing this? See below for the code. The code snippet below illustrates the process described above.

	@Override
	public void setInput(final Object input) {
		if (input instanceof ICompareInput) {
			final ICompareInput compareInput = (ICompareInput) input;
			final ICompareAccessor left = getCompareAccessor(compareInput.getLeft());
			final ICompareAccessor right = getCompareAccessor(compareInput.getRight());
		}
	}

	private static ICompareAccessor getCompareAccessor(final ITypedElement typedElement) {
		if(!(typedElement instanceof AccessorAdapter)) {
			return null;
		}

		final Object target = ((AccessorAdapter) typedElement).getTarget();
		return target instanceof ICompareAccessor ? (ICompareAccessor) target : null;
	}
Re: Custom content merge viewer [message #1857435 is a reply to message #1850532] Tue, 07 February 2023 17:17 Go to previous message
Philip Alldredge is currently offline Philip AlldredgeFriend
Messages: 20
Registered: February 2013
Junior Member
We have our plugin working as desired. However, in the process we ultimately required the usage of several internal APIs. We ended up not extending org.eclipse.compare.contentmergeviewer.ContentMergeViewer. This provided additional flexibility for the content merge viewer's layout. That doesn't seem to be required by the org.eclipse.compare.contentMergeViewers extensionpoint.

We used the following internal APIs in our plugin:

NoLoadingResourceSet.setAllowResourceLoad - We temporarily toggle this in some cases when we need proxies to be resolved by the Xtext language implementation that is being used.

Needed to implement content merge viewer creators without reimplementing things:
EMFCompareConfiguration
EMFCompareConfiguration.EMFCompareConfiguration(CompareConfiguration)
EMFCompareConfiguration.setLabelProvider
EMFCompareConfiguration.getLeftLabel
EMFCompareConfiguration.getRightLabel
EMFCompareConfiguration.getContainer
EMFCompareConfiguration.getEditingDomain
EMFCompareConfiguration.getEventBus
EMFCompareConfiguration.getComparison
EMFCompareConfiguration.isLeftEditable
EMFCompareConfiguration.isRightEditable
TreeNodeCompareInputLabelProvider - Used with EMFCompareConfiguration

To filter the content merge viewer content based on the structure merge viewer filters
EMFCompareConfiguration.setLabelProvider.getStructureMergeViewerGrouper().getProvider()
EMFCompareConfiguration.setLabelProvider.getStructureMergeViewerFilter().getAggregatedPredicate()

AccessorAdapter - Needed to get the accessors produced by accessor factories. See last post. I never found a way to do what was needed with the public APIs.

The following internal APIs are used as part of the automated UI tests:
Navigatable
EMFCompareStructureMergeViewer
CompareContentViewerSwitchingPane
CompareInputAdapter


Previous Topic:No merger found for diff AttributeChangeSpec
Next Topic:EMF Compare shows only text compare
Goto Forum:
  


Current Time: Thu Apr 25 17:37:20 GMT 2024

Powered by FUDForum. Page generated in 0.05460 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top