Home » Modeling » Graphiti » TransactionalEditingDomain, separate model files, and the diagram
TransactionalEditingDomain, separate model files, and the diagram [message #869705] |
Thu, 03 May 2012 22:56 |
Josef Pohl Messages: 82 Registered: January 2012 |
Member |
|
|
Hi there,
I am trying to understand a few concepts concerning the TransactionalEditingDomain and the model and diagram files. I hope that someone can give a brief explanation.
Right now I create a diagram and create a separate Resource for both the model file and the diagram. It goes something like this:
// This is in "CreateDiagram"
ResourceSet resourceSet = new ResourceSetImpl();
TransactionalEditingDomain editingDomain = TransactionUtil.getEditingDomain(resourceSet);
...
AddDiagram operation = new AddDiagram(project, editingDomain, diagramName);
and then in AddDiagram
// created uri for diagram file above.... now create Resource
createdResource = editingDomain.getResourceSet().createResource(uri);
createdResource.getContents().add(diagram);
// created uri for model file above ... now create Resource
createdModelResource = editingDomain.getResourceSet().createResource(uriModel);
// add previously created model element to resource
createdModelResource.getContents().add(sc);
// add same element to business objects related to diagram
PictogramLink link = PictogramsFactory.eINSTANCE.createPictogramLink();
diagram.setLink(link);
link.getBusinessObjects().add(sc);
createdResource.setTrackingModification(true);
createdModelResource.setTrackingModification(true);
try{
createdResource.save(Collections.EMPTY_MAP);
createdModelResource.save(Collections.EMPTY_MAP);
}catch(IOException e) { ... }
Later on back in the original class (CreateDiagram)
// execute the AddDiagram operation
editingDomain.getCommandStack().execute(operation);
try {
operation.getCreatedResource().save(null);
} catch (IOException e) {
// catchy
}
// Dispose the editing domain to eliminate memory leak
editingDomain.dispose();
// Open the editor
String platformString = operation.getCreatedResource().getURI().toPlatformString(true);
IFile file = project.getParent().getFile(new Path(platformString));
IFileEditorInput input = new FileEditorInput(file);
try {
PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().openEditor(input, DiagramEditor.DIAGRAM_EDITOR_ID);
} catch (PartInitException e) {
...
}
When I want to add a new feature related to a model element I use something like:
getDiagram().eResource().getContents().add(newClass);
What I am trying to understand is what is maintaining the connection between the diagram, the editing domain, and the model?
It seems odd to me that the editingDomain is disposed. The only connection I can ascertain from all of this is the link between the business object (sc) above and the diagram. sc itself has no graphical component.
Is the editingDomain, or more to the point the ResourceSet, attached to the diagram more persistent than I am aware, or than it appears?
The getDiagram().eResource()... sort of implies that there is a single resource.
But upon doing this, the resource that the newClass is added to is the model file, not the diagram. Or so I am guessing that this is what occurs.
Does anyone have an intuitive sense of what is going on here? Or perhaps could point me in a good direction to figure this out?
Thanks in advance,
Joe
|
|
| |
Re: TransactionalEditingDomain, separate model files, and the diagram [message #869886 is a reply to message #869840] |
Fri, 04 May 2012 15:59 |
Josef Pohl Messages: 82 Registered: January 2012 |
Member |
|
|
Thanks for the response, as always, Michael.
The reason I am digging into this is that I noticed that when the copy and paste is implemented one can copy in between diagrams as expected. However, in the case where the diagram and model file are distinct files (Resources), when a paste occurs between diagrams the model element is removed from the first (source) model file and added to the second (the target model file). Which is presumably desired, or at least expected, behavior. Except that it puts the original diagram into a really bad state.
Hence I am trying to determine if I can create a second diagram that either maintains the element in both model files (which will probably cause no end of consistency issues) or attach the model file from the original diagram to the new diagram.
I think in both circumstances I will have to have a special version of the "CreateDiagram" functionality. Is there any best practices with respect to this kind of behavior, or is it fundamentally discouraged one way or another?
Thanks again for your response. It clarified the issue for me.
Thanks,
Joe
|
|
| | |
Re: TransactionalEditingDomain, separate model files, and the diagram [message #873346 is a reply to message #870535] |
Fri, 18 May 2012 02:52 |
Josef Pohl Messages: 82 Registered: January 2012 |
Member |
|
|
Hi there,
I finally had the chance to get back to this and was wondering if anyone could throw some guidance my way.
I have implemented a custom feature which when run creates a new diagram. This
new diagram was implemented to use the same model file as the original. As I conjectured in my last note, it did cause all sorts of problems.
I have a set up similar to the tutorial in that I call a create diagram method that sets up the TransactionalEditingDomain and an operation to add the new diagram.
This part seems to work OK. The new diagram gets created and I can add elements to the new diagram that show up in the original diagrams model file... temporarily...
This is where the issues begin.
When I add elements to the new diagram I begin to get errors. The first is if I return to the original diagram (bring that diagram back to being active) I get a "File Conflict" error stating "There are unsaved changes that conflict with changes made outside the editor. Do you wish to discard this editor's changes?"
One thing I noted was that as soon as I opened the new diagram the state of the original went to unsaved (dirty?). Anytime I save one diagram, the other goes into the unsaved state.
Anyhow, the issues sort of cascade from there. If I close the diagram and re-open it the elements are in a dirty state and no longer exist in the model file.
Here is how I set up the diagram and the model file.
protected void doExecute() {
//Create the diagram and its file
Diagram diagram = Graphiti.getPeCreateService().createDiagram("egsndiagram", diagramName, true);
IFolder diagramFolder = project.getFolder("src/diagrams/");
IFile diagramFile = diagramFolder.getFile(diagramName + ".diagram");
URI uri = URI.createPlatformResourceURI(diagramFile.getFullPath().toString(), true);
IFile diagramFileModel = diagramFolder.getFile(modelName);
URI uriModel = URI.createPlatformResourceURI(diagramFileModel.getFullPath().toString(), true);
createdResource = editingDomain.getResourceSet().createResource(uri);
createdResource.getContents().add(diagram);
//final SafetyCase sc = XxegsnFactory.eINSTANCE.createSafetyCase();
PictogramLink link = PictogramsFactory.eINSTANCE.createPictogramLink();
diagram.setLink(link);
createdModelResource = editingDomain.getResourceSet().getResource(uriModel, true);
EList<EObject> elist = createdModelResource.getContents();
SafetyCase sc = null;
for (EObject eo: elist){
if(eo instanceof SafetyCase){
sc = (SafetyCase) eo;
}
}
link.getBusinessObjects().add(sc);
IDiagramTypeProvider dtp = GraphitiUi.getExtensionManager().createDiagramTypeProvider(diagram,
"diagram.EgsndiagramTypeProvider");
IFeatureProvider featureProvider = dtp.getFeatureProvider();
createdResource.setTrackingModification(true);
createdModelResource.setTrackingModification(true);
try{
createdResource.save(Collections.EMPTY_MAP);
createdModelResource.save(Collections.EMPTY_MAP);
}catch(IOException e) {}
}
Is there any way to get the two diagrams to play nicely with the same model resource? Or does anyone have a better way of doing this? My only requirement is that the model file has to be treated as a whole for later analysis.
Thanks,
Joe
|
|
|
Re: TransactionalEditingDomain, separate model files, and the diagram [message #884770 is a reply to message #873346] |
Mon, 11 June 2012 19:42 |
Josef Pohl Messages: 82 Registered: January 2012 |
Member |
|
|
Hi there,
So I am still struggling with coming up with a good structure for linking two diagrams. I have constructed a model that works OK up until modifications are made on a diagram that affects the relative position of the elements in the model resource. Then everything seems to go out of state.
Again, what I am trying to do is have multiple diagrams that are related to the same
model instance.
So I might have the following structure
D1 -- Diagram 1 (the original)
D2 -- Diagram 2 (spawned from the first and related by an element on the first which is also graphically represented on the second)
(D3 ... Dn -- however many other diagrams that follow the same scenario as D2)
M -- A model resource which contains all the elements and relations for Diagram 1 and Diagram 2
So the scenario I am currently implementing is that
Diagram 1 has a resource set that contains a Diagram resource (Rd1) and a model resource (Mr) loaded into its TransactionalEditingDomain (TED).
Diagram 2 has a resource set that contains a Diagram resource (Rd2) and a model resource generated from the same persisted file as Mr.
Everything seems to work fine if I only add elements to Rd2 and hence Mr.
However if I start to edit, in particular remove, elements from Rd1 then Rd2 goes out of state. This is due to the relative nature of the element relationships between the diagram resource and the model resource (i.e. making such references to nodes in a relative way from the diagram resource. In the persisted version this shows up as //@node.2 for instance). If I were to, for instance delete a node from Rd1 which appeared above elements connected to Rd2, then the ordering in Rd2 is off and the Rd2 element refers to the wrong element in the model resource (Mr).
Now, I suspect there is a way to get the diagram (D2 for instance) to listen to these changes. I am not certain how to set up the listener just yet. Does anyone have any thoughts on this?
However there is also the question on how to reflect these changes to the diagram D2 when these changes are made in D1 if D2 is not open?
So does anyone have a better scenario than this for making connections between diagrams? And for keeping the model instances (and references between the model and diagram) fresh?
Thanks!
Joe
|
|
| |
Re: TransactionalEditingDomain, separate model files, and the diagram [message #886889 is a reply to message #885158] |
Fri, 15 June 2012 19:39 |
Josef Pohl Messages: 82 Registered: January 2012 |
Member |
|
|
Hi Michael,
I asked a question (in a different forum) about creating the named references a long time ago but no one had an answer for me. I did figure it out though and it did take care of some of my issues.
So from what I have read in this forum (in the backlog) what I am trying to do should, theoretically, work. I am still confronted by a few issues though.
Again, I am trying to have two diagram editors access and modify the same resource.
Now one thing that I am doing is when I generate the second diagram I am creating a separate resource for that diagram and link the top level element (SafetyCase element) to the diagram. I use an existing display element to connect the two diagrams. The element is a GA/Container linked to a business object. I call the element the pivot point.
PictogramLink link = PictogramsFactory.eINSTANCE.createPictogramLink();
diagram.setLink(link);
createdModelResource = editingDomain.getResourceSet().getResource(uriModel, true);
EList<EObject> elist = createdModelResource.getContents();
SafetyCase sc = null;
for (EObject eo: elist){
if(eo instanceof SafetyCase){
sc = (SafetyCase) eo;
}
}
link.getBusinessObjects().add(sc);
I am not certain if I am doing this incorrectly.
Here is some the errant behavior that I am seeing:
Whenever I launch a new diagram:
a) The state of the original diagram is dirty (unsaved)
b) When I return to the original diagram I get the following "File Conflict" message: "There are unsaved changes that conflict with changes made outside the editor. Do you wish to discard this editors changes?"
Clicking yes or no will modify the "state" depending on what was just done.
For instance if I click yes right after creating the new diagram, saving it and returning to the original diagram, it will remove the graphical changes that I have made (basically an extra GA that shows it is a "connected node") but still allow the element on the new and old diagram to be connected to the same BO. If I say No it
leaves the new GA but the BO is removed from the Resource and hence neither element is connected either to each other or any element at all.
I am not certain if I need to be modifying or adding any hooks to other listeners (or where even to add those hooks or changes in general)? Is there anything else that you can think of that I can fiddle around with that would keep the three resources (both of the diagram resources and the model resources (which is really two separate resources itself) ) playing nicely with each other?
Thanks,
Joe
PS. Michael, we submitted and had accepted a workshop paper using this graphiti based tool. We would like to acknowledge your help in the final version if that is acceptable to you. You can send me a private message if you want.
|
|
| | | | |
Goto Forum:
Current Time: Thu Mar 28 16:52:44 GMT 2024
Powered by FUDForum. Page generated in 0.04793 seconds
|