Make model browsers ownership concept extendible #3567
Conversation
|
I don't see any changes here to the .gaphor models for Core and UML. What do they look like with this approach? Also, if Core has an ownership relation and the language model has similar relations, what's involved in keeping them synchronized? Language-specific logic that updates the Core ownership relation when the language-specific relation changes? How do you deal with a tree drag-and-drop that moves an element to another location in the tree? |
|
Changes to the model come later. Once the concept of ownership is separated from the model browser, I can start implementing different variations: two for UML, one for diagrams. In the end I plan to move the Element class to the UML model.
I have to figure out parts of that still. I think I need something like a service that notifies the model browser when an element's owner has changed. The ultimate goal would be to make the model browser modeling language agnostic. But that'll take several PR's to achieve. |
b0719aa to
fbba30b
Compare
e47f067 to
35ad318
Compare
Now we can easily differentiate between items that should be on the root level, and elements that should not be shown (None).
Now that owner can be None and Root.
35ad318 to
d954865
Compare
PR Type
What kind of change does this PR introduce?
What is the current behavior?
The model browser mainly depends on the
Element.owner/ownedElementrelationship for ownership.It also supports
memberNamespace, mainly for association ends without owner.Builds on #3568.
Issue Number: #3540
Fixes #3557
What is the new behavior?
Separate the concept of ownership out of the model browser, so it can be extended.
The
owner()dispatch method tells who's the owner of an element: another element,Root, orNone. In case ofNone, the element is not supposed to be shown in the model browser.Does this PR introduce a breaking change?
A separate element ownership function.
Other information
The only issue is that event handling (in
ModelBrowser) still checks for the properties used. This should change at some point, but I think this is already a nice simplification.I do love to get rid of the
owns()dispatch function -- basically the counterpart ofowner()-- but I have no idea how, yet.