Community
Participate
Working Groups
Currently, specific profiles are allowed to contribute their own IPapyrusElementProvider, which will be used to customize the DOM Model on which CSS will be applied. This is used, for example, to support CSS Properties that are not directly related to semantic UML or Stereotype properties (For example, to find the "Name of a Type" of a Property, or to identify all "deprecated" elements of SysML 1.4) In most cases, these providers simply contribute new properties to an existing DOM Model, so it should be possible to enable all of them on the same DOM. However, with the current design, only one provider will be enabled for each Diagram, and this provider is determined as soon as the diagram is loaded. As a consequence, for example, the SysML Provider will not be applied if we load a UML Diagram, and then apply the SysML profile on it (We need to reopen the Papyrus Editor entirely, to reload the Notation resource). Another consequence is for Papyrus Compare: the model is initially loading with proxy resolution turned off (So it's not possible for the SysML provider to detect that the SysML Profile is applied on a Diagram), and proxy resolution is allowed only when the comparison is complete (At this point, Diagrams have already been loaded with a UML DOM Model). As a result, some SysML CSS properties are not supported by the Compare Diagram Viewer. In theory, the DOM Providers are also allowed to customize the DOM Structure, but in practice, I don't think any of them uses that feature (At most, they customize the name of an existing element, but that's done in the UML Provider directly, and they all either inherit from that, or copy/paste this behavior, so there shouldn't be any conflict)
To clarify the intention of this ticket: the idea is to improve the extension point used to provide custom IPapyrusElementProvider, in order to support multiple contributions at the same time on each diagram. This would allow multiple languages to work together in a diagram, and would reduce the risk of some providers not being used when they should be. This would also limit the risk of conflicts and redundancies, as well as the amount of copy/paste between providers in each language. In practice, custom DOM Providers would probably be refactored to "Property contributors" (Partial DOM Participants), rather than full "DOM Tree Providers"
@Benoit: Do you know if there's a reason for SysML to contribute its own GMFSYSMLElementAdapter extending directly GMFElementAdapter, rather than extending GMFUMLElementAdapter? It seems that most of GMFSYSML is copied from GMFUML anyway, so why not inherit from it, and just add the few SysML-specific properties?
@Camille: my memory doesn't got this far :p So based on gerrit/bugzilla: The GMFSYSMLElementAdapter class was introduced 2 years and 10 months ago https://git.eclipse.org/r/#/c/55571/ The GMFUMLElementAdapter was open as API shortly after (2 years and 7 month ago) https://git.eclipse.org/r/#/c/62793/ => so the class was duplicated because it was impossible to inherit from it at the time (be careful, it may also have some performance reason) I think that extension point for partial dom instead full dom is a very very good idea. I can't pronounce on the use case for Papyrus compare but I'm not sure that the expected result is to use GMFSYSMLElementAdapter when having an UML diagram with the SysML profile. With the new architecture framework, I would expect to have it only if the diagram kind is owned by the SysML Architecture framework. /Benoît
> With the new architecture framework, I would expect to have it only if the diagram kind is owned by the SysML Architecture framework. Yeah that would probably be an option, too. I'm not too sure how we want to handle standard UML Diagrams profiled with SysML. But I don't see any reason why the SysML properties (Such as deprecated) shouldn't work in that case. Regarding the stylesheet itself; that's a different story. For now, it's applied by the SysML architecture (e.g. IBD), but users might still want to provide their own stylesheets, and still use e.g. the deprecated CSS property for sysml. The expectation in Papyrus Compare is simple: the diagram should look the same when rendered in Papyrus, and when compared with an older version of itself. So if the SysML provider is enabled in Papyrus, it should also be enabled in the Papyrus Compare Diagram Viewer. Anyway, I think all DOM providers should be enabled at all time, but only provide values for their custom properties if the expected Diagram/Profile/Architecture/Whatever is enabled (So they would check more often for these conditions, rather than checking only once when the notation resource is loaded)
