Eclipse Community Forums: Compare » StructureMergeViewerFilter and EObject Adapter content

Help

Home

Home » Modeling » Compare » StructureMergeViewerFilter and EObject Adapter content

Show: Today's Messages :: Show Polls :: Message Navigator

StructureMergeViewerFilter and EObject Adapter content [message #1067749]

Wed, 10 July 2013 12:39

Noé A Rodríguez González

Messages: 4
Registered: July 2013

Junior Member

Hi:
I have been using EMF compare viewers to show a comparison tree. I would like to customize the comparison tree showed by the EMFCompareStructuralMergeViewer.
It´s possible to add content using a customized contentProvider that extends, for example, MatchItemProviderSpec. However the classStructureMergeViewerFilter filters any content that is not instance of a few clases. There is a piece of code in StructureMergeViewerFilter to take into account generic content (like adatper of EObject) but I think it´s placed in such a way that it is never called.

1.- Unreachable code in StructureMergeViewerFilter line 116:

   if (getPredicates().isEmpty()) {
                  result = true;
            } else if (element instanceof Adapter) {
                    ....
              } else if (element instanceof Adapter && ((Adapter)element).getTarget() instanceof EObject)   {
                     // Unreachable code
         }

The unreachable code may be integrated into the "if" block in line 93 being the resulting code something like that:

   if (getPredicates().isEmpty()) {
                                   result = true;
                        } else if (element instanceof Adapter) {
                                   Notifier notifier = ((Adapter)element).getTarget();
                                   if (notifier instanceof Diff) {
                                               final Diff diff = (Diff)notifier;
                                               result = !predicate.apply(diff);
                                   } else if (notifier instanceof Match) {
                                               final Match match = (Match)notifier;
                                               result = !predicate.apply(match);
                                               if (result && !Iterables.isEmpty(match.getAllDifferences())) {
                                                           final Iterator<Diff> differences = match.getAllDifferences().iterator();
                                                           return Iterators.any(differences, not(predicate));
                                               }
                                   } else if (notifier instanceof MatchResource) {
                                               final MatchResource matchResource = (MatchResource)notifier;
                                               result = !predicate.apply(matchResource);
                                   } else if (notifier instanceof Conflict) {
                                               final Iterator<Diff> differences = ((Conflict)notifier).getDifferences().iterator();
                                               result = Iterators.any(differences, not(predicate));
                                   } if (((Adapter)element).getTarget() instanceof EObject) {                                   
                                               final EObject target = (EObject)((Adapter)element).getTarget();
                                               result = !predicate.apply(target);
                                    }
                        } else if (element instanceof IDifferenceGroup) {
                                   final Iterator<? extends Diff> differences = ((IDifferenceGroup)element).getDifferences()
                                                           .iterator();
                                   result = Iterators.any(differences, not(predicate));
                        }

2.- Extra elements could appear in EMFCompareStructureMergeViewer. If the modification to avoid the unreachable code is made. Any Eobject Adapter is taken into account for filtering and not automatically excluded, as it was originally happening. Therefore elements provided for the ItemProviders like Equivalences would be present in the tree of the EMFcompareStructureMergeViewer. If this elements are no required to be showed they may not be provided by the MatchItemProviderSpec.

3.- It´s looks like there are various "if" blocks for specific clases that could be resolved with the generic case of eobject. Cases for
Diff, Conflict, MatchResource have the same code and could be resolved with the EObject case.

Thanks.

Report message to a moderator

Re: StructureMergeViewerFilter and EObject Adapter content [message #1067899 is a reply to message #1067749]

Thu, 11 July 2013 07:46

Axel RICHARD

Messages: 43
Registered: September 2010
Location: France

Member

Hi Noé,

You're right for the three points. We're currently refactoring this part. A review has been submitted (https://git.eclipse.org/r/#/c/14129/) and will be available soon.

Axel.

Axel Richard
Obeo

Report message to a moderator

Re: StructureMergeViewerFilter and EObject Adapter content [message #1072253 is a reply to message #1067899]

Mon, 22 July 2013 11:51

Noé A Rodríguez González

Messages: 4
Registered: July 2013

Junior Member

Hi:

Thank you very much! We are currently making use of this feature so we are hightly interested on the refactoring you are working on Smile

Report message to a moderator

Re: StructureMergeViewerFilter and EObject Adapter content [message #1073319 is a reply to message #1072253]

Wed, 24 July 2013 14:12

Laurent Goubet

Messages: 1902
Registered: July 2009

Senior Member

Hi Noé,

The way we display differences has now been deeply refactored, and you might not be able to use the same classes as before. Mainly, we no longer use the ItemProviders since they restricted way too much the way we wanted to show things to the user.

You might look at the final form of https://git.eclipse.org/r/#/c/14129/ as it's been merged on the repository. Basically, your entry point are now IDifferenceGroups, you can look at how we build the actual tree in BasicDifferenceGroup#getGroupTree(). Please do not hesitate to tell us if this new way of doing things is too restrictive for your needs, and how we could improve the design of that API.

Laurent Goubet
Obeo

Report message to a moderator

Previous Topic:	On suboptimal decisions over the match solution spectrum
Next Topic:	On EMF Compare 2.X scalability

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 20:11:23 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter