Community
Participate
Working Groups
There is an ambiguity as to whether EDiagram displays a view of a sub-set of an Ecore model, or the whole model. Both are useful. EDiagram currently only does the former. This has the surprising effect that creating a class or reference and then deleting it does not delete it from the Ecore model. Other tools have distinct delete-from-diagram/delete-from-model capability. I think the current delete-from-diagram is correct in the diagram, but that delete-from-model should be supported in the Outline view, together with a variety of other reparenting type edits. The New Wizard, and ChangeEcores page (once written) should have a check box attribute to indicate whether each resource is read-only with a default coming from the file-system when there is ambiguity. [?There could be another check-box attribute to indicate whether a diagram is a complete or sub-set view of the primary model.]
Found KEY_PERM_DELETE so Ctrl+Delete provides the notional functionality. Supporting it on the OutlinePage is just a nicety. Though other reparenting edits and read-only support are still necessary. Unforunately permanent delete does not work. It deletes all graphical connections but does not remove the reverse links, e.g an inheritance of a deleted class, or an eOpposite for a reference. I think it is misguided to support all appropriate link deletions in nodes. Better for a node deletion to prefix link deletion commands to the compound command that deletes the node. The node is then an orphan when it is deleted, and the link deletion code gets re-used for node deletion. The same applies hierarchically when a package is deleted.
I now have a package of delete commands that I think is correctly functional. I separated model and view delete commands, so that a non-permanent delete just invokes a simple view delete that zaps the graphics only, and a permanent delete invokes a model delete. The model delete creates a chain of pre- requisite child deletes that get executed first. These child deletes may be classes-before-package, or inheritance-before-class in the model domain, and also view-deletes for each deleted model element. Creating view-deletes from the model-delete localises the functionality and keeps undo trivial. It should also ensure that all diagrams sharing the same ResourceSet are kept consistent. The resulting code is distinctly simpler. The wizard creations need a mechanism to share rather than create a ResourceSet. As it stands my improved code uses generics and my IRegime registered creation mechanism. It shouldn't be too hard to do a manual type erasure so that the code can be incorporated without a style drift. I'll try to resolve this as soon as I've verified that my separated view/model functionality extends comfortably to view/referencing-model/referenced-model.
(In reply to comment #1) > Unforunately permanent delete does not work. It deletes all graphical > connections but does not remove the reverse links, e.g an inheritance > of a deleted class, or an eOpposite for a reference. This is your only complaint in terms of behaviour, right? It would be nice if we did it for them, but that would mean we'd have to search every class to see if it was referencing the deleted class. Plus, some of those changes might not be apparent to the user. I think it's fine to expect the user to fix any references to the deleted elements (at least for now).
I think this is an example of where minor improvements to EDiagram are difficult. Leaving some things to the user is plausible, if the user knows. In EDiagram the user doesn't. In UMLX the user does, because the final stage of graphical refresh is to check changed elements (needsMarker()) and to update problem markers to show where intervention is needed. (Many of those that appear reveal bugs in the code.) In UMLX, resolution of references is aided by using the Ecore Adapter mechanism. Every Ecore element has a CoModelAdapter that maintains the graphical instantiations of the element on a per-sheet basis. Finding graphics is easy and uniform. Introduction of the intermediate transient Ecore2 layer with E2Inheritance and E2Association relationships makes eSupertypes and EReference behave in a consistent way for the graphics, but I'm never quite sure whether the extra level of listening is really a winner. I suggest a WONTFIX for EDiagram.
helpwanted
(In reply to comment #5) > helpwanted What form of help from whom? If you mean from me, then it's hard. I found that the lack of a clean model structure meant that it was very hard to progress. Hence the very substantial structural changes in UMLX that enable these problems to be resolved. If you choose to regard UMLX as an official successor to EDiagram the problems are resolved. If you proceed with EDiagram as-is there are liable to be an unceasing stream of minor funnies that prevent the quality moving from useful to reliable. The current very instanceof dependent coding style cannot really be an example of good practice.
Ed, helpwanted is a keyword that gef clients can search for to find potential contribution areas to GEF (see the help wanted link on our webpage).
LATER and REMIND resolutions will be going away with the upgrade of Bugzilla to the latest Bugzilla 3.4. They are no longer part of the default Bugzilla installation. See http://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg00778.html for the announcement. As a result RESOLVED + REMIND OR LATER will be changed to RESOLVED + WONTFIX This unfortunately also means I need to REOPEN and then RESOLVE as WONTFIX Sorry for the inconvenience.
