Community
Participate
Working Groups
BasicNodeViewFactory uses Unprotected Transaction for creating views. Usually it can get away with it but sometimes it causes problems. When View#setElement() is called in Unprotected Transaction then a change object does not get created for this operation. Now after Undo the reference set by setElement call would not get cleaned and cross reference adapters will still this (dead) View as referencing the semantic element. Now if you try to delete the sem element it would not work, because some Advice will search for all Views referencing the sem element and find our dead one and try to delete it and fail because it is already dead. The Delete operation for semantic element will fail. The element becomes "undeletetable".
Committed the fix for 2.1.1. Now we record the setting of semantic element reference for decorating views.
I'm looking into the change made to BasicNodeViewFactory, and kind of stuck trying to understand the reason to wrap node.setElement() into a separate operation. The comment there states the reason is to record #setElement() with a change recorder. However, once Node is added into a Diagram (ViewUtil.insertChildView()), it gets TransactionalChangeRecorder installed and #setElement() change *is* recorded (provided there's outer transactional operation) and then the change is undone correctly (View.unsetElement()). Besides, the previous fix for the same problem (bug #186637, which actually moved #setElement() invocation *after* ViewUtil.insertChildView()) suggests my perspective makes sense. Could you please explain this to me?
Suppose, you need to create a view and you already have an outer write transaction that's recordable. So the view is created attached to the parent and semantic element is set, all these things are recorded. Then you decorate the view install styles, set various structural features and attach extra views to the created one such as compartments, labels etc. So these decorating views may have a semantic element different from the parent view (the one that's being decorated with compartments, labels, etc.). Suppose a view is decorated with a compartment view that has a different semantic element. Decoration of a view runs in s silent not recordable transaction for some optimization reasons. However, we should record the setting of the semantic element for decorating view, such that this reference can be unset on undo. Hope this helps.
[GMF Restructure] Bug 319140 : product GMF and component Runtime Diagram was the original product and component for this bug
