|
|
| Re: Graphiti without transactional editing domain? [message #647971 is a reply to message #647905] |
Mon, 10 January 2011 16:13   |
 Jos Warmer
Messages: 114
Registered: October 2010 |
Senior Member |
|
|
Michael,
Getting rid of the transactional editing domain seems to be hard indeed. So I am now looking at a solution where we use an editing domain. I have been able to create a Graphiti diagram stored in a file, referring to domain objects stored in CDO. To enable this I had to make a few changes in the Graphiti code:
In DiagramEditorfactory.createResourceSetAndEditingDomain() a new resource set and a new transactional editing domain is created. I changed this to use the CDO resource set instead, which contains our domain objects. This enables Graphiti to find the referred domain objects. Also we are using a static shared editing domain, so I changed the code to use our shared editing domain instead of creating a new one.
In DiagramEditorInput.dispose() I removed the line disposing the editing domain. This results in an error because you cannot (and should not) dispose a shared editing domain.
In EmfService..save(...) all the resources are saved, including the domain resource. As we save the CDO resource in a special way, I have added a check to only save non-CDO resources.
It isn't that much work, but pretty hard to find exactly where to make these changes.
The next step will be to get rid of the file storage for the diagram. We will create the diagram in memory, completely derived from the domain model. We the need to open a Graphiti editor on the in-memory Graphiti model. I have seen a number of places in the Graphiti code where the assumption seems to be that a diagram is stored in a file and probably need to make some changes for this to work as well.
Another step, but much further away, is enable storage of the Graphiti diagrams in CDO, instead of in a file.
If you have any advise or tips on how to open a diagram from an in-memory Graphiti model let me know. Otherwise I will tell you afterward how we did this  .
Jos
|
|
|
| Re: Graphiti without transactional editing domain? [message #648171 is a reply to message #647971] |
Tue, 11 January 2011 15:38 |
Michael Wenz
Messages: 1931
Registered: July 2009
Location: Walldorf, Germany |
Senior Member |
|
|
Jos,
that sounds good so far! :-)
Were you able to do all the changes in your own subclasses or did you need
to change the framework itself? At least everthing you mentioned is public
API besides the EmfService. Maybe it would be better to change the save
behvior in your own subclass of DiagramEditor?
Regarding the in-memory diagram: actually I would hope that the editor and
the framework itself does not rely on diagrams being stored in a resource, I
would expect such things in services and the way the example common plugin
works.
You should be able to use the method
PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActi vePage().openEditor
to open the editor passing the DiagramEditor id
(DiagramEditor.DIAGRAM_EDITOR_ID) and a DiagramEditorInput. Creating the
latter one could be the biggest issue since in the standard framework you
would need a TransactionalEditingDomain to do so, but maybe you have already
changed there...
Just let me know of your progress.
Michael
"Jos Warmer" <jos.warmer@openmodeling.nl> wrote in message
news:igfasn$it2$1@news.eclipse.org...
> Michael,
>
> Getting rid of the transactional editing domain seems to be hard indeed.
> So I am now looking at a solution where we use an editing domain. I have
> been able to create a Graphiti diagram stored in a file, referring to
> domain objects stored in CDO. To enable this I had to make a few changes
> in the Graphiti code:
>
> In DiagramEditorfactory.createResourceSetAndEditingDomain() a new
> resource set and a new transactional editing domain is created. I changed
> this to use the CDO resource set instead, which contains our domain
> objects. This enables Graphiti to find the referred domain objects. Also
> we are using a static shared editing domain, so I changed the code to use
> our shared editing domain instead of creating a new one.
>
> In DiagramEditorInput.dispose() I removed the line disposing the editing
> domain. This results in an error because you cannot (and should not)
> dispose a shared editing domain.
>
> In EmfService..save(...) all the resources are saved, including the domain
> resource. As we save the CDO resource in a special way, I have added a
> check to only save non-CDO resources.
>
> It isn't that much work, but pretty hard to find exactly where to make
> these changes.
> The next step will be to get rid of the file storage for the diagram. We
> will create the diagram in memory, completely derived from the domain
> model. We the need to open a Graphiti editor on the in-memory Graphiti
> model. I have seen a number of places in the Graphiti code where the
> assumption seems to be that a diagram is stored in a file and probably
> need to make some changes for this to work as well.
> Another step, but much further away, is enable storage of the Graphiti
> diagrams in CDO, instead of in a file.
>
> If you have any advise or tips on how to open a diagram from an in-memory
> Graphiti model let me know. Otherwise I will tell you afterward how we
> did this :) .
>
> Jos
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02951 seconds
] 
Search
Help
Register
Login
Home
