Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Graphiti » Compatibility with EMF/CDO
Compatibility with EMF/CDO [message #853585] Mon, 23 April 2012 06:32 Go to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 854
Registered: July 2009
Senior Member
Is it possible to use CDO to store/load the pictogram model to/from?
And, of course, to link the pictogram model to the CDO model?
Re: Compatibility with EMF/CDO [message #853706 is a reply to message #853585] Mon, 23 April 2012 09:02 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1931
Registered: July 2009
Location: Walldorf, Germany
Senior Member
That's possible, but I have to admit that I have never tried it myself.

There's an integration of Graphiti editors in Dawn which is sitting on top
of CDO with an example editor for ACore models. Maybe that helps...

Michael
Re: Compatibility with EMF/CDO [message #854001 is a reply to message #853706] Mon, 23 April 2012 14:56 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 854
Registered: July 2009
Senior Member
I managed to load the pictogram model...
Though, I had to use internal code to manually/programmatically load the editor... Is this the right way?

public Object execute(ExecutionEvent event) throws ExecutionException {
		ResourceSet rs = new ResourceSetImpl();
		Resource r = rs.createResource(URI.createFileURI("c:/diagram.xmi"));
		Diagram diag = Graphiti.getPeService().createDiagram(
				"my.diagramType1", "name", true);
		r.getContents().add(diag);
		try {
			r.save(null);
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		GraphitiUiInternal.getWorkbenchService().openDiagramEditor(diag,
				"my.diagramTypeProvider");
		return null;
	}

Re: Compatibility with EMF/CDO [message #854730 is a reply to message #854001] Tue, 24 April 2012 07:37 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1931
Registered: July 2009
Location: Walldorf, Germany
Senior Member
The probably better way would be to create a DiagramEditorInput for your
diagram (passing the URL of your diagram) and then using the Eclipse
platform methods openEditor() e.g. on the WokbenchPage.

Michael
Re: Compatibility with EMF/CDO [message #854808 is a reply to message #854730] Tue, 24 April 2012 08:54 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 854
Registered: July 2009
Senior Member
Is it ok to instantiate a Diagram, then pass its URI to the editor input, then re-instantiate it in the editor? What if I have processed the initially created Diagram, e.g. added some adapters to it? Will this be managed by the resource or by emf?
Re: Compatibility with EMF/CDO [message #854830 is a reply to message #854808] Tue, 24 April 2012 09:11 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1931
Registered: July 2009
Location: Walldorf, Germany
Senior Member
The editor will come up with a new resource/resourceSet/editingDomain
combination, so none of the stuff you set at your diagram instance on
creation outside of the editor will get into the editor.

So I would recommend to add these adapters inside the editor. Otherwise you
might run into issues: if the registration happens outside on digram
creation, the adapters will only be active for newly created diagrams not
for diagrams opened from an existing file.

Michael
Re: Compatibility with EMF/CDO [message #865386 is a reply to message #854830] Mon, 30 April 2012 11:28 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 854
Registered: July 2009
Senior Member
Now, building the Diagram instance just by its URI does not seem to work in CDO:
The emf internals seem to get the CDOResource properly, but, the CDOResource is not bound to a CDO View. To get a CDO View, you have to authenticate (at least in our application) and all that funny stuff which does not work here...

Is it possible to re-use the Diagram instance which is provided to the DiagramEditorInput? Are there any critical requirements to have the Diagram being created by its URI?

Michael Wenz wrote on Tue, 24 April 2012 05:11
The editor will come up with a new resource/resourceSet/editingDomain
combination, so none of the stuff you set at your diagram instance on
creation outside of the editor will get into the editor.

So I would recommend to add these adapters inside the editor. Otherwise you
might run into issues: if the registration happens outside on digram
creation, the adapters will only be active for newly created diagrams not
for diagrams opened from an existing file.

Michael

Re: Compatibility with EMF/CDO [message #868576 is a reply to message #865386] Wed, 02 May 2012 08:44 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1931
Registered: July 2009
Location: Walldorf, Germany
Senior Member
The rationale behind is that if the editor creates the EditingDomain it is
also responsible for disposing it again, freeing the memory needed for the
loaded EObjects. Genrally that's easier for clients to handle.

To achieve what you want you may override DiagramEditor and change the
init() stuff were the domain is created and reuse what you like here. The
dispose() should then be adapted as well.

Michael
Re: Compatibility with EMF/CDO [message #870197 is a reply to message #868576] Mon, 07 May 2012 08:43 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 854
Registered: July 2009
Senior Member
So, I have derived my EditorPart from DiagramEditor like the following...

Problem: When dropping objects from the palette, the appropriate AddFeature/CreateFeature of the diagram feature provider is called, but the visual elements are not shown in the editor. Did I skip some important settings? Or maybe, I am missing some additional settings in my custom editor?

@Override
	public void init(IEditorSite site, IEditorInput input)
			throws PartInitException {
		getUpdateBehavior().createEditingDomain();

		// super.super.init(...);
		{
			setSite(site);
			setInput(input);
			getCommandStack().addCommandStackListener(this);
			getSite().getWorkbenchWindow().getSelectionService()
					.addSelectionListener(this);
			initializeActionRegistry();
		}

		getUpdateBehavior().init();
	}

	@Override
	protected void doSetInput(IEditorInput input) {
		MyEditorInput diagramEditorInput = (MyEditorInput) input;

		// determine filename
		Assert.isNotNull(input, "The IEditorInput must not be null"); //$NON-NLS-1$
		Diagram diagram = diagramEditorInput.getDiagram();

		// can happen if editor is started with invalid URI
		Assert.isNotNull(diagram, "No Diagram found for URI '" //$NON-NLS-1$
				+ "'. . See the error log for details."); //$NON-NLS-1$

		String providerId = diagramEditorInput.getProviderId();

		Assert.isNotNull(
				providerId,
				"DiagramEditorInput does not convey a Provider ID '" + diagramEditorInput //$NON-NLS-1$
						+ "'. . See the error log for details."); //$NON-NLS-1$

		// get according diagram-type-provider
		IDiagramTypeProvider diagramTypeProvider = GraphitiUi
				.getExtensionManager().createDiagramTypeProvider(providerId);
		Assert.isNotNull(
				diagramTypeProvider,
				"could not find diagram type provider for " + diagram.getDiagramTypeId()); //$NON-NLS-1$

		diagramTypeProvider.init(diagram, this);
		IConfigurationProvider configurationProvider = new ConfigurationProvider(
				this, diagramTypeProvider);
		setConfigurationProvider(configurationProvider);
		getRefreshBehavior().handleAutoUpdateAtStartup();

		registerBusinessObjectsListener();
		registerDiagramResourceSetListener();

		refreshTitle();
	}

	@Override
	public void doSave(IProgressMonitor monitor) {
		getResourceAccess().save();
	}


Notes:

- I have changed the visibility of some protected methods to public
- I have refactored the contents of org.eclipse.graphiti.ui.editor.DiagramEditor.setInput(IEditorInput) and introduced a doSetInput to allow to call EditorInput.setInput
Re: Compatibility with EMF/CDO [message #870234 is a reply to message #870197] Mon, 07 May 2012 11:59 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 854
Registered: July 2009
Senior Member
I solved the problem this way... It was due to different ResourceSets, I had to re-use the Diagram's ResourceSet...

	@Override
	public void init(IEditorSite site, IEditorInput input)
			throws PartInitException {
		MyEditorInput diagramEditorInput = (MyEditorInput) input;
		ResourceSet resourceSet = diagramEditorInput.getDiagram().eResource()
				.getResourceSet();
		final IWorkspaceCommandStack workspaceCommandStack = new GFWorkspaceCommandStackImpl(
				new DefaultOperationHistory());

		final TransactionalEditingDomainImpl editingDomain = new TransactionalEditingDomainImpl(
				new ComposedAdapterFactory(
						ComposedAdapterFactory.Descriptor.Registry.INSTANCE),
				workspaceCommandStack, resourceSet);
		WorkspaceEditingDomainFactory.INSTANCE.mapResourceSet(editingDomain);
		getUpdateBehavior().initializeEditingDomain(editingDomain);

		// super.super.init(...);
		{
			setSite(site);
			setInput(input);
			getCommandStack().addCommandStackListener(this);
			getSite().getWorkbenchWindow().getSelectionService()
					.addSelectionListener(this);
			initializeActionRegistry();
		}

		getUpdateBehavior().init();
	}


Re: Compatibility with EMF/CDO [message #870492 is a reply to message #870234] Tue, 08 May 2012 12:19 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 854
Registered: July 2009
Senior Member
This is the minimally customized DiagramEditor sub class that seems to work:


import org.eclipse.core.commands.operations.DefaultOperationHistory;
import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.resource.ResourceSet;
import org.eclipse.emf.edit.provider.ComposedAdapterFactory;
import org.eclipse.emf.transaction.impl.TransactionalEditingDomainImpl;
import org.eclipse.emf.workspace.IWorkspaceCommandStack;
import org.eclipse.graphiti.mm.pictograms.Diagram;
import org.eclipse.graphiti.ui.editor.DefaultPersistencyBehavior;
import org.eclipse.graphiti.ui.editor.DefaultUpdateBehavior;
import org.eclipse.graphiti.ui.editor.DiagramEditor;
import org.eclipse.graphiti.ui.editor.DiagramEditorInput;
import org.eclipse.graphiti.ui.internal.editor.GFWorkspaceCommandStackImpl;
import org.eclipse.ui.IEditorInput;
import org.eclipse.ui.IEditorSite;
import org.eclipse.ui.PartInitException;

public class CustomDiagramEditor extends DiagramEditor {
	public static class CustomDiagramEditorInput extends DiagramEditorInput {
		private Diagram diagram;

		public CustomDiagramEditorInput(Diagram diag, String providerId) {
			super(URI.createFileURI("" + System.currentTimeMillis()),
					providerId);
			this.diagram = diag;
		}

		public Diagram getDiagram() {
			return diagram;
		}
	}

	private CustomDiagramEditorInput editorInput;

	@Override
	protected DefaultPersistencyBehavior createPersistencyBehavior() {
		return new DefaultPersistencyBehavior(this) {
			@Override
			public Diagram loadDiagram(URI uri) {
				return editorInput.getDiagram();
			}
		};
	}

	@Override
	protected DefaultUpdateBehavior createUpdateBehavior() {
		return new DefaultUpdateBehavior(this) {
			@Override
			protected void createEditingDomain() {
				ResourceSet resourceSet = editorInput.getDiagram().eResource()
						.getResourceSet();
				final IWorkspaceCommandStack workspaceCommandStack = new GFWorkspaceCommandStackImpl(
						new DefaultOperationHistory());

				final TransactionalEditingDomainImpl editingDomain = new TransactionalEditingDomainImpl(
						new ComposedAdapterFactory(
								ComposedAdapterFactory.Descriptor.Registry.INSTANCE),
						workspaceCommandStack, resourceSet);
				// WorkspaceEditingDomainFactory.INSTANCE.mapResourceSet(editingDomain);
				initializeEditingDomain(editingDomain);
			}
		};
	}

	@Override
	public void init(IEditorSite site, IEditorInput input)
			throws PartInitException {
		assert input instanceof CustomDiagramEditorInput;
		editorInput = (CustomDiagramEditorInput) input;
		super.init(site, input);
	}
}


Maybe, it would be good to let the diagram editor input handle load/save and do not make any assumptions on how to do this in the DiagramEditor (persistence behavior would have to be in the editor input)... This would allow for better re-use of the diagram editor, wouldn't it?
Re: Compatibility with EMF/CDO [message #874744 is a reply to message #870492] Mon, 21 May 2012 13:27 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1931
Registered: July 2009
Location: Walldorf, Germany
Senior Member
Moving this to the input seems to be a good idea, however has some
limitations. An input needs to be a very lightweight object as it tends to
live for a long time (it's held by the Eclipse editor history - back and
forward buttons in the toolbar) and must not reference an editing domain and
its resource set because that would also keep all EObjects used in the
diagram. That would cause a really big memory footprint.

In 0.9.0 we did a rework of the editor and extracted some aspects into
seperate classes. One of theses aspects is the persistency behavior of the
editor. I think, this should be an alternative solution to what you propose?

Michael
Re: Compatibility with EMF/CDO [message #874767 is a reply to message #874744] Mon, 21 May 2012 14:03 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 854
Registered: July 2009
Senior Member
Thanks, so, the way it is done above (return custom XYBehavior in a subclass of DiagramEditor) is ok?
Re: Compatibility with EMF/CDO [message #875103 is a reply to message #874767] Tue, 22 May 2012 06:40 Go to previous message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1931
Registered: July 2009
Location: Walldorf, Germany
Senior Member
Yes, that's the intended way to change the default behaviors.

Michael
Previous Topic:E4 - Graphiti - without compatibility layer?
Next Topic:Group Elements
Goto Forum:
  


Current Time: Thu Apr 18 02:45:57 GMT 2024

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

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

Back to the top