Hi Cédric,
Ø Which lead me to this question : why don't you, in the papyrus code, directly refers to the Factory you want to use (here the one having the CSS support) It is actually impossible to call our own Factory, because EMF Factories are called from everywhere. We'd need to rewrite for example the XML Handler, because the default behavior is to retrieve the factory associated to a specific Ns URI: factory = ePackage.getEFactoryInstance(); And it's impossible to find all usages of this pattern, because they are spread amongst all EMF-based components (Including generic ones: we'd need to rewrite all generic resources). I highly doubt that the overhead is even noticeable for components, when the CSS Support is not explicitly installed. It is a matter of ~10 microseconds for each style call, and there aren't so many calls (Because "getFillColor" is only called when e.g. refreshing the edit part, or displaying the Appearance properties). Ø Furthermore your code might assume things which are just not true for other modelers, like the fact that the model is in a ResourceSet or even in a Resource. The only assumption is that, if there is an EditingDomain, then there should be a ResourceSet. If the View is not located in a Resource, or the Resource is not associated to an EditingDomain, then it does nothing. I've just added a test to handle the case where we have a non-null EditingDomain with a null ResourceSet (Which seems a little bit unlikely, but one never knows). Thanks for your feedback Regards, Camille De : [email protected] [mailto:[email protected]] De la part de Cédric Brun Envoyé : jeudi 19 décembre 2013 17:35 À : [email protected] Objet : Re: [cross-project-issues-dev] Papyrus: CSS Support for GMF Hi and thanks for the heads-up. You're right this would impact every GMF modeler out there (EcoreTools being one of them) and lead to issues quite difficult to identify and fix. Which lead me to this question : why don't you, in the papyrus code, directly refers to the Factory you want to use (here the one having the CSS support) - or even define your own extension point to retrieve the right one in the context of papyrus ? What is the rationale to override the GMF one for all the Eclipse Installation ? Even if this does not introduce any specific bug or issue, just that fact that it might lookup the ResourceSet for the CSS support could lead to performance penalty for all the modelers - not something we could afford for no gain on the other hand. Furthermore your code might assume things which are just not true for other modelers, like the fact that the model is in a ResourceSet or even in a Resource. Cédric Le 17/12/2013 18:13, LETAVERNIER Camille a écrit : Hi all, In Papyrus, we've implemented a component to support CSS Stylesheets for GMF-based diagrams. This component has been introduced in Papyrus/Juno, and we now consider it stable. It has never been included in the Simultaneous Release because of one specific issue: this component overrides the GMF Notation metamodel implementation (Though the org.eclipse.emf.ecore.factory_override extension point). Because the EMF Factory is a singleton, there is a risk of introducing conflicts, if more than one component uses this extension point for the same metamodel. The CSSNotation elements have been designed to delegate to the standard Notation implementation when the CSS support is not installed on the resource set, which means that this component, in theory, doesn't introduce any change in the behavior of non-Papyrus diagrams. Now, we'd like to distribute this component as part of the Papyrus project for Luna, directly in the Release Train, whereas it was only proposed as an optional, extra component in Juno and Kepler. My idea is that we might introduce this feature in M4, and remove it before M6 if major issues (incompatibilities) are introduced. Is there any objection, or suggestion? (Especially for GMF-based projects) Regards, Camille __________________________ Camille Letavernier CEA LIST Papyrus : http://www.eclipse.org/papyrus _______________________________________________ cross-project-issues-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
