Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Graphiti » Graphiti without transactional editing domain?
Graphiti without transactional editing domain? [message #646925] Mon, 03 January 2011 08:47 Go to next message
Jos Warmer is currently offline Jos WarmerFriend
Messages: 114
Registered: October 2010
Senior Member
We are going to use Graphiti with a domain model that is stored using CDO. The EMF TransactionalEditingDomain does not always work well together with CDO, therefore we are looking into the possibility of using Graphiti without a transactional editing domain (at least for the domain model, for the Diagram it should probably ok). Does anyone know whether this is possible?

Jos
Re: Graphiti without transactional editing domain? [message #647905 is a reply to message #646925] Mon, 10 January 2011 12:01 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1923
Registered: July 2009
Location: Walldorf, Germany
Senior Member
Jos,

that will get kind of hard. Graphiti uses the transactional stuff as a kind
of bracket aound each operation. A RecordingCommand is executed each time a
feature is executed to get the connection to undo/redo and to actually
trigger an undo. So this is really wover tightly into the framework.

The diagram and domain objects need to be loaded using the same resource set
to be able to link objects. So you will either have everything inside a
TransactionalEditingDomain or in a CDO resource set. I don't think the
mixture is possible.

Maybe somebody else has other ideas?

Michael


"Jos Warmer" <jos.warmer@openmodeling.nl> wrote in message
news:ifs25l$7cu$1@news.eclipse.org...
> We are going to use Graphiti with a domain model that is stored using CDO.
> The EMF TransactionalEditingDomain does not always work well together with
> CDO, therefore we are looking into the possibility of using Graphiti
> without a transactional editing domain (at least for the domain model, for
> the Diagram it should probably ok). Does anyone know whether this is
> possible?
>
> Jos
Re: Graphiti without transactional editing domain? [message #647971 is a reply to message #647905] Mon, 10 January 2011 16:13 Go to previous messageGo to next message
Jos Warmer is currently offline Jos WarmerFriend
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 Smile .

Jos
Re: Graphiti without transactional editing domain? [message #648171 is a reply to message #647971] Tue, 11 January 2011 15:38 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1923
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
Re: Graphiti without transactional editing domain? [message #649588 is a reply to message #646925] Wed, 19 January 2011 20:08 Go to previous messageGo to next message
Jos Warmer is currently offline Jos WarmerFriend
Messages: 114
Registered: October 2010
Senior Member
I had the code in the Graphiti code. When I try to chnage it as you propose I get a nullpointerexeption in:

	protected CommandStack getCommandStack() {
		return getEditDomain().getCommandStack();
	}
.
The only thing I do in my own editor input is to set the diagram explicitly, because I have build it in memory. I also use my own editing domain.

See :
!ENTRY org.eclipse.ui 4 0 2011-01-19 21:03:06.013
!MESSAGE Unable to create editor ID com.systemizeit.pmw.diagrams.PmwEditor: An exception was thrown during initialization
!STACK 0
java.lang.NullPointerException
at org.eclipse.gef.ui.parts.GraphicalEditor.getCommandStack(Gra phicalEditor.java:252)
at org.eclipse.gef.ui.parts.GraphicalEditor.init(GraphicalEdito r.java:347)
at org.eclipse.graphiti.ui.internal.editor.DiagramEditorInterna l.init(DiagramEditorInternal.java:1082)
at org.eclipse.ui.internal.EditorManager.createSite(EditorManag er.java:798)
at org.eclipse.ui.internal.EditorReference.createPartHelper(Edi torReference.java:647)
at org.eclipse.ui.internal.EditorReference.createPart(EditorRef erence.java:465)
at org.eclipse.ui.internal.WorkbenchPartReference.getPart(Workb enchPartReference.java:595)
at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:31 3)
at org.eclipse.ui.internal.presentations.PresentablePart.setVis ible(PresentablePart.java:180)
at org.eclipse.ui.internal.presentations.util.PresentablePartFo lder.select(PresentablePartFolder.java:270)
at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrd er.select(LeftToRightTabOrder.java:65)
at org.eclipse.ui.internal.presentations.util.TabbedStackPresen tation.selectPart(TabbedStackPresentation.java:473)
at org.eclipse.ui.internal.PartStack.refreshPresentationSelecti on(PartStack.java:1254)
at org.eclipse.ui.internal.PartStack.setSelection(PartStack.jav a:1207)
at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:16 06)
at org.eclipse.ui.internal.PartStack.add(PartStack.java:497)
at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103 )
at org.eclipse.ui.internal.PartStack.add(PartStack.java:483)
at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112 )
at org.eclipse.ui.internal.EditorSashContainer.addEditor(Editor SashContainer.java:63)
at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorA reaHelper.java:225)
at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAre aHelper.java:213)
at org.eclipse.ui.internal.EditorManager.createEditorTab(Editor Manager.java:778)
at org.eclipse.ui.internal.EditorManager.openEditorFromDescript or(EditorManager.java:677)
at org.eclipse.ui.internal.EditorManager.openEditor(EditorManag er.java:638)
at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched( WorkbenchPage.java:2860)
at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(Workben chPage.java:2768)
at org.eclipse.ui.internal.WorkbenchPage.access$11(WorkbenchPag e.java:2760)
at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.j ava:2711)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:70)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPa ge.java:2707)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPa ge.java:2691)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPa ge.java:2674)
Re: Graphiti without transactional editing domain? [message #674651 is a reply to message #649588] Fri, 27 May 2011 17:41 Go to previous message
Shenxue Zhou is currently offline Shenxue ZhouFriend
Messages: 60
Registered: July 2009
Member
Hi Jos,

We're also interested in using in-memory diagram (not associate a diagram with a file). Reading this topic, it seems that you've made good progress in that direction. I'm interested in hearing any update you might have. Have you succeeded in getting rid of diagram's file association?

Thanks!

Shenxue
Previous Topic:What do I need to install Graphiti?
Next Topic:Edit Model using Commands
Goto Forum:
  


Current Time: Sun Nov 29 23:22:36 GMT 2020

Powered by FUDForum. Page generated in 0.02172 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top