Bugzilla – Full Text Bug Listing
| Summary: | simple diagram changes like move or resize change the (xtext) business model | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] Graphiti | Reporter: | Henrik Rentz-Reichert <hrr> | ||||
| Component: | Core | Assignee: | Project Inbox <graphiti-inbox> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | michael.wenz | ||||
| Version: | 0.7.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Henrik Rentz-Reichert
Created attachment 185766 [details]
ScreenShot1 showing how to create a structure diagram
Henrik, the reason for this is that the editing domain used in the diagram editor contains both the diagram and the domain resource. On saving, all resources of the editor are saved (see the Graphiti class EmfService method save). You could prevent saving your resource by enabling modification tracking on it. In that case it will only be saved if it was really changed. Please let me know if that helps. Michael Michael,
thanks for your reply.
The good news is that it works now.
But as my business resource is loaded when the contents of the graphical viewer is created I have not found yet a good place to switch modification tracking on.
I've tried overriding initializeGraphicalViewer() in my StructureEditor class which extends org.eclipse.graphiti.ui.editor.DiagramEditor
@Override
protected void initializeGraphicalViewer() {
super.initializeGraphicalViewer();
ResourceSet rs = getEditingDomain().getResourceSet();
if (rs.getResources().size()>1)
rs.getResources().get(1).setTrackingModification(true);
}
But since the super class method (and also getEditingDomain()) is implemented in org.eclipse.graphiti.ui.internal.editor.DiagramEditorInternal I get a 'Discouraged access' warning.
Any recommendation?
Thanks,
Henrik
Henrik, no really well worked-out ones... One idea was to use a ResourceSetListener on the editing domain to actually enable the modification tracking for the loaded resources (that would also enable resources loaded after the initialization phase of the editor). Not sure if that works... Another alternative would be to handle saving by yourself (by overriding doSave in the editor). But that would require that you can find out which resources were really modified. But this might turn out to be an issue that other users of Graphiti also run into. Michaek Michael, I also can't anticipate future requirements of your clients. For the time being (and my purpose) it would be sufficient to create a hook in the public API like protected void postInit() which can be overridden in derived classes. It would also be necessary to have public TransactionalEditingDomain getEditingDomain() in the public API (protected access would be sufficient). It might be a general problem for your clients that every method you override in your internal package, e.g. in the DiagramEditorInternal, is hidden from the clients due to access restrictions. And this is so even if the super class defining this method is in the public API. But I also don't have experiences with this kind of questions. Henrik Henrik, would such a hook really be sufficient for your usecase? Don't you have the situation that additional resources might get loaded after the editor initialization? That was my point... The editor being in the internal packages is surely an issue we need to think about. Michael Michael, I assumed that when I access model elements (business objects) from other resources I will be able to switch on modification tracking. But may be you are right and a more general mechanism would be desirable. In this case the ResourceSetListener might be a good means. But if the EditingDomain is accessible also the ResourceSet is and the client can add his own ResourceSetListener, right? Henrik Henrik, sorry, this somehow dropped off my radar... The answer to your question is, yes you are able to register such listeners; be sure to de-register it again. Regarding the warnings when overriding DiagramEditorInternal methods I would suggest to open up a seperate bugzilla to track opening necessary methos in DiagramEditor. Michael The problem described here could be solved (see above). So I closed this bug. I have opened bug 336488 to track the remaining access rule problem. Closed |