Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Compare » StructureMergeViewerFilter and EObject Adapter content
StructureMergeViewerFilter and EObject Adapter content [message #1067749] Wed, 10 July 2013 12:39 Go to next message
Noé A Rodríguez González is currently offline Noé A Rodríguez González
Messages: 2
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.

Re: StructureMergeViewerFilter and EObject Adapter content [message #1067899 is a reply to message #1067749] Thu, 11 July 2013 07:46 Go to previous messageGo to next message
Axel RICHARD is currently offline Axel RICHARD
Messages: 17
Registered: September 2010
Location: France
Junior 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
Re: StructureMergeViewerFilter and EObject Adapter content [message #1072253 is a reply to message #1067899] Mon, 22 July 2013 11:51 Go to previous messageGo to next message
Noé A Rodríguez González is currently offline Noé A Rodríguez González
Messages: 2
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.








Re: StructureMergeViewerFilter and EObject Adapter content [message #1073319 is a reply to message #1072253] Wed, 24 July 2013 14:12 Go to previous message
Laurent Goubet is currently offline Laurent Goubet
Messages: 1625
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
Previous Topic:On suboptimal decisions over the match solution spectrum
Next Topic:On EMF Compare 2.X scalability
Goto Forum:
  


Current Time: Tue Sep 23 10:34:59 GMT 2014

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

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