diff options
| author | Pierre-Charles David | 2014-08-22 13:12:21 +0000 |
|---|---|---|
| committer | Maxime PORHEL | 2014-09-03 08:11:47 +0000 |
| commit | a4ba105590228efbe30bfa9bde4509a23b061865 (patch) | |
| tree | f137e431b06535fd7b5e6c40478f8e52a56ba04e | |
| parent | f4e8ccfb3defc2d8ef19e09d001e57b4dbc5f4a0 (diff) | |
| download | org.eclipse.sirius-a4ba105590228efbe30bfa9bde4509a23b061865.tar.gz org.eclipse.sirius-a4ba105590228efbe30bfa9bde4509a23b061865.tar.xz org.eclipse.sirius-a4ba105590228efbe30bfa9bde4509a23b061865.zip | |
[442337] Optimized implementation of DialectManager.getRepresentations()
When DialectManager.getRepresentations() is called with a non-null
semantic element, we can use the session's semantic cross-referenced to
find all DRepresentations pointing to it in consant time, instead of
iterating over a potentially large list of representations.
The new version also avoids delegating the computation to each dialect
in turn. In practice all the (current) core dialects do it the same way,
so the search was done N times (N being the number of available
dialects), each dialect returning a sub-set of elements, and then the
results were aggregated. Note that this change has two potential issues:
1. It makes Sirius incompatible with "exotic" dialects which would store
their DRepresentation out of the scope of the search and/or would not
use DSemanticDecorator.target to link their representations to the
underlying semantic element. In practice, I suspect other parts of
Sirius would break or behave strangely with dialects storing their
DRepresentations in non-standard places. As for the
DSemanticDecorator issue, the interface provides a single "target"
EReference, so it is not a huge constraint to require all
DRepresentations to implement it. It could/should probably be
enforced directly in the metamodel (getting rid of DSemanticDiagram
along the way).
2. The new implementation does not test that the DRepresentation is
finds are actually compatible/handled by one of the active dialects.
In non standard circumstances, we could have the metamodel of a
dialect available (which allowed us to load the DRrepresentation
instances) with the dialect itself not registered in the
DialectManager (maybe the extension point is in a separate plug-in
which is not started yet). In that case we can return
DRepresentations that none of the active dialects understands.
Bug: 442337
Change-Id: Ic5cbfa8d82d95a34b1ca4af216b3a468c9fe61a1
Signed-off-by: Pierre-Charles David <pierre-charles.david@obeo.fr>
| -rw-r--r-- | plugins/org.eclipse.sirius/src/org/eclipse/sirius/business/internal/dialect/DialectManagerImpl.java | 27 |
1 files changed, 23 insertions, 4 deletions
diff --git a/plugins/org.eclipse.sirius/src/org/eclipse/sirius/business/internal/dialect/DialectManagerImpl.java b/plugins/org.eclipse.sirius/src/org/eclipse/sirius/business/internal/dialect/DialectManagerImpl.java index e201086a2f..32be09988c 100644 --- a/plugins/org.eclipse.sirius/src/org/eclipse/sirius/business/internal/dialect/DialectManagerImpl.java +++ b/plugins/org.eclipse.sirius/src/org/eclipse/sirius/business/internal/dialect/DialectManagerImpl.java @@ -22,6 +22,7 @@ import org.eclipse.core.runtime.NullProgressMonitor; import org.eclipse.core.runtime.SubProgressMonitor; import org.eclipse.emf.ecore.EObject; import org.eclipse.emf.ecore.EStructuralFeature; +import org.eclipse.emf.ecore.util.ECrossReferenceAdapter; import org.eclipse.sirius.business.api.dialect.Dialect; import org.eclipse.sirius.business.api.dialect.DialectManager; import org.eclipse.sirius.business.api.dialect.RepresentationNotification; @@ -39,11 +40,14 @@ import org.eclipse.sirius.tools.api.command.CommandContext; import org.eclipse.sirius.tools.api.command.ui.UICallBack; import org.eclipse.sirius.viewpoint.DRepresentation; import org.eclipse.sirius.viewpoint.SiriusPlugin; +import org.eclipse.sirius.viewpoint.ViewpointPackage; import org.eclipse.sirius.viewpoint.description.RepresentationDescription; import org.eclipse.sirius.viewpoint.description.RepresentationExtensionDescription; import org.eclipse.sirius.viewpoint.description.Viewpoint; import org.eclipse.sirius.viewpoint.description.tool.ModelOperation; +import com.google.common.collect.Lists; + /** * Class able to manage a set of dialects to provides the usual dialect services * using the Eclipse environment. @@ -255,11 +259,26 @@ public class DialectManagerImpl implements DialectManager { * org.eclipse.sirius.business.api.session.Session) */ public synchronized Collection<DRepresentation> getRepresentations(final EObject semantic, final Session session) { - final Collection<DRepresentation> reps = new ArrayList<DRepresentation>(); - for (final Dialect dialect : dialects.values()) { - reps.addAll(dialect.getServices().getRepresentations(semantic, session)); + if (semantic != null) { + return findAllRepresentations(semantic, session); + } else { + final Collection<DRepresentation> reps = new ArrayList<DRepresentation>(); + for (final Dialect dialect : dialects.values()) { + reps.addAll(dialect.getServices().getRepresentations(semantic, session)); + } + return reps; } - return reps; + } + + private Collection<DRepresentation> findAllRepresentations(EObject semantic, Session session) { + Collection<DRepresentation> result = Lists.newArrayList(); + ECrossReferenceAdapter xref = session.getSemanticCrossReferencer(); + for (EStructuralFeature.Setting setting : xref.getInverseReferences(semantic)) { + if (ViewpointPackage.Literals.DREPRESENTATION.isInstance(setting.getEObject()) && setting.getEStructuralFeature() == ViewpointPackage.Literals.DSEMANTIC_DECORATOR__TARGET) { + result.add((DRepresentation) setting.getEObject()); + } + } + return result; } /** |
