Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Graphiti » Saving only the domain model
Saving only the domain model [message #726907] Mon, 19 September 2011 21:43 Go to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member
I'm exploring the possibility of working with the Graphiti editor in a "model only" scenario: only the model would be saved to a file, and the diagram would be entirely recreated (with the corresponding addFeature, as hinted in other threads) each time the editor opens the model.

I would like that file to be restricted to my model (i.e., no graphiti resources or packages would be saved, nowhere). This seems possible, but it seems that I would need to reimplement the DiagramEditorFactory.createEditorInput() , and/or the DiagramEditorInput class itself.

Another option I was thinking was to save an empty diagram, seems to be easier to do the loading (but slightly more difficult to save it; and it'd prefer to avoid the coupling). Any experiences or suggestions?
Re: Saving only the domain model [message #727442 is a reply to message #726907] Wed, 21 September 2011 10:15 Go to previous messageGo to next message
Felix Velasco is currently offline Felix VelascoFriend
Messages: 43
Registered: July 2009
Member
We've run into a similar problem, and solved it using a resource with a "virtual" uri. We implemented a URIHandler that stores the info in memory, in a byte[]. This way, graphiti "stores" its graphical model, but only in memory, where it can be easily deleted after closing the editor.
Re: Saving only the domain model [message #727613 is a reply to message #727442] Wed, 21 September 2011 16:14 Go to previous messageGo to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member
Felix Velasco wrote on Wed, 21 September 2011 07:15
We've run into a similar problem, and solved it using a resource with a "virtual" uri. We implemented a URIHandler that stores the info in memory, in a byte[]. This way, graphiti "stores" its graphical model, but only in memory, where it can be easily deleted after closing the editor.


I've thinking on something like that (sort of a "/dev/null" uri, one that writes nowhere...). This might solve (albeit a little hackishly) the save, it would remain to (re)implement the DiagramEditorInput so that it works from a file/uri that points to a model-only xml file. Working on that, we'll see.
Thanks.
Re: Saving only the domain model [message #727971 is a reply to message #727613] Thu, 22 September 2011 10:17 Go to previous messageGo to next message
Felix Velasco is currently offline Felix VelascoFriend
Messages: 43
Registered: July 2009
Member
There's no need to change DiagramEditorInput. If you create the Diagram in a resource with in a virtual uri, linked to bo's in a normal resource, and both of then belong in the same editingDomain, you can use the uri constructor with the virtual uri.
This is the (edited) body of a method we use to create the DiagramEditorInput in our project.

Diagram diagram = Graphiti.getPeCreateService().createDiagram(diagramType, title, true);

// Create a virtual URI with a custom schema
URI uri = URI.createHierarchicalURI(VirtualURIHandler.VIRTUAL_URI_SCHEMA,
		null,
		null,
		new String[] { "diagram", id },
		null,
		null);

// Create a regular resource in the uri, in the EditingDomain that already contains the model
final Resource diagramResource = commonEditingDomain.getResourceSet().createResource(uri);				


// Add the diagram to the resource
commonEditingDomain.getCommandStack().execute(new AbstractCommand() {

	@Override
	protected boolean prepare() {
		return true;
	}

	@Override
	public void execute() {
		diagramResource.getContents().add(diagram);
	}

	@Override
	public void redo() {
	}
		
});		

String providerId = GraphitiUi.getExtensionManager().getDiagramTypeProviderId(diagram.getDiagramTypeId());		
return new DiagramEditorInput(uri, commonEditingDomain, providerId);
Re: Saving only the domain model [message #728223 is a reply to message #727971] Thu, 22 September 2011 18:37 Go to previous messageGo to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member
Felix Velasco wrote on Thu, 22 September 2011 07:17
There's no need to change DiagramEditorInput. If you create the Diagram in a resource with in a virtual uri, linked to bo's in a normal resource, and both of then belong in the same editingDomain, you can use the uri constructor with the virtual uri.

This is the (edited) body of a method we use to create the DiagramEditorInput in our project...


Thanks! I'll try this way - I don't know why I was adamant about my DiagramEditorInput having as its URI that of the real file, I see now that there's no need for that.

You didn't extend/change DiagramEditorInput but, I guess, you extended/changed the DiagramEditorFactory or the DiagramEditorInternal.init() method, right?
Re: Saving only the domain model [message #729911 is a reply to message #728223] Tue, 27 September 2011 09:16 Go to previous messageGo to next message
Felix Velasco is currently offline Felix VelascoFriend
Messages: 43
Registered: July 2009
Member
Yes, we extended the DiagramEditor and customized it.
Re: Saving only the domain model [message #733470 is a reply to message #727442] Tue, 04 October 2011 20:14 Go to previous messageGo to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member
Felix Velasco wrote on Wed, 21 September 2011 07:15
We've run into a similar problem, and solved it using a resource with a "virtual" uri. We implemented a URIHandler that stores the info in memory, in a byte[]. This way, graphiti "stores" its graphical model, but only in memory, where it can be easily deleted after closing the editor.


Just in case someone is interested in knowing: it does not seem to be necessary to store the diagram in memory, I implemented this same idea with a virtual uri handle that sends the bytes nowhere (sort of a /dev/null device) and it worked (till now). AFAIK the editor does not read the diagram execpt that when loading (or reloading).
Re: Saving only the domain model [message #755486 is a reply to message #733470] Tue, 08 November 2011 16:11 Go to previous messageGo to next message
Christian B is currently offline Christian BFriend
Messages: 68
Registered: August 2011
Member
hey Hernan,
i'd be interested in your solution, can you post the relevant code snippets?

thx!
Re: Saving only the domain model [message #755757 is a reply to message #755486] Wed, 09 November 2011 14:01 Go to previous messageGo to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member
buschcobolt wrote on Tue, 08 November 2011 13:11
hey Hernan,
i'd be interested in your solution, can you post the relevant code snippets?


I'd love to, but unfortunately my current working solution relies on a substantial rewrite I did of DiagramEditor/DiagramEditorBehavior (including the removing of DiagramEditorInput) to allow for clean choosing/customization of persistence, without needing to mess with DiagramEditorInternal:

( In my schema, all "persistence related intelligence" (Diagram creation, loading, saving, detecting changes to eclipse resources or to emf resources made from outside) is delegated to the DiagramEditorBehavior, which is a public (not internal) class. The DiagramEditor acts as a (customizable) factory of its DiagramEditorBehavior (the user can extend the standard implementation, or choose or implement another), and they talk to each other across a restricted set of methods. The intented goal is that DiagramEditorInternal (and all internal code) never makes any assumption about the editor input format. I'll post details soon, when I have this more stabilized, if there's interest. )

In my scenario (model-only persistence), I implemented a rather trivial NullURIHandler - I copy the code below, but I'm afraid this will be too little to be useful

/** urihandler for virtual uri that writes in a pseudo /dev/null */
public class NullURIHandler implements URIHandler {

	private static final String SCHEMADEFAULT = "devnull";

	public final String schema;

	public NullURIHandler() {
		this(SCHEMADEFAULT);
	}

	public NullURIHandler(String schema) {
		this.schema = schema;
	}

	/**
	 * transforms a fileUri to a virtualuri, changing the schema
	 */
	public URI createForDiagram(URI fileUri) {
		return URI.createHierarchicalURI(schema, fileUri.authority(), fileUri.device(), fileUri.segments(), null, null);
	}

	@Override
	public boolean canHandle(URI uri) {
		return schema.equals(uri.scheme());
	}

	@Override
	public InputStream createInputStream(URI uri, Map<?, ?> options) throws IOException {
		return new InputStream() {
			@Override
			public int read() throws IOException {	return -1;}
		};
	}

	@Override
	public OutputStream createOutputStream(URI uri, Map<?, ?> options) throws IOException {
		return new OutputStream() {
			@Override
			public void write(int b) throws IOException {	}
		};
	}

	@Override
	public void delete(URI uri, Map<?, ?> options) throws IOException {	}

	@Override
	public Map<String, ?> contentDescription(URI uri, Map<?, ?> options) throws IOException {
		return new HashMap<String, String>();
	}

	@Override
	public boolean exists(URI uri, Map<?, ?> options) {
		return true;
	}

	@Override
	public Map<String, ?> getAttributes(URI uri, Map<?, ?> options) {
		return new HashMap<String, String>();
	}

	@Override
	public void setAttributes(URI uri, Map<String, ?> attributes, Map<?, ?> options) throws IOException {
		System.err.println(getClass() + ".setAttributes() not implemented ");
	}

}





Re: Saving only the domain model [message #755953 is a reply to message #755757] Thu, 10 November 2011 10: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
"Hernan" schrieb im Newsbeitrag news:j9e0cl$h4p$1@news.eclipse.org...

>( In my schema, all "persistence related intelligence" (Diagram creation,
>loading, saving, detecting changes to eclipse resources or to emf resources
>made from outside) is delegated to the DiagramEditorBehavior, which is a
>public (not internal) class. The DiagramEditor acts as a (customizable)
>factory of its DiagramEditorBehavior (the user can extend the standard
>implementation, or choose or implement another), and they talk to each
>other across a restricted set of methods. The intented goal is that
>DiagramEditorInternal (and all internal code) never makes any assumption
>about the editor input format. I'll post details soon, when I have this
>more stabilized, if there's interest. )

Yes, there's definitely interest in this...

Michael
Re: Saving only the domain model [message #756253 is a reply to message #755953] Fri, 11 November 2011 16:36 Go to previous messageGo to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member
Michael Wenz wrote on Thu, 10 November 2011 07:11


Yes, there's definitely interest in this...

Michael


Thanks, I'll try to work on this this weekend.

Some dev questions:

1) I'm novice at API Tooling. Suppose I'm coding some classes changes that break API compatibility (needless to say ... Razz ) , should I use @since 0.9 or @since 1.0 ? (of course, we are speaking of changes done in a branch of my own, which might never be merged into the real Graphiti release)

2) I know nothing about Buckminster/Hudson - should I care?

3) Is this forum the right place to ask these questions and discuss development issues? The other channels I'm currently aware of are :

the mailing-list (mostly for announcements, it seems)
http://dev.eclipse.org/mhonarc/lists/graphiti-dev/threads.html

the bugzilla (for specific issues)
https://bugs.eclipse.org/

the developer wiki (docs/recipes/knowledge base)
http://wiki.eclipse.org/GMP/Graphiti


Re: Saving only the domain model [message #758020 is a reply to message #756253] Mon, 21 November 2011 15:31 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1931
Registered: July 2009
Location: Walldorf, Germany
Senior Member
Hi Hernan,

1) in that case we currently add a @since 0.9 tag. In case we switch to
1.0.0 in Juno timeframe we will migrate all 0.9 tags to 1.0 tags.
2) For now you do not need to care, Hudson will simply use Buckminster to
build to newest Git repository content. Of course that changes in case you
need something build relevant...
3) For Bugzilla and Wiki this is correct. This forum is mainly intended for
questions on the usage of Graphiti. The graphiti-dev mailing list would be
the better place to discuss framework development related things. Currently
it is not yet used for that, but the only reason is that until now all
framework developers are co-located here in Walldorf. That defenitly will
change so I gues that the dev mailing list will become more relevant over
time.

Michael
Re: Saving only the domain model [message #1709359 is a reply to message #726907] Sun, 27 September 2015 18:36 Go to previous message
Anton Huck is currently offline Anton HuckFriend
Messages: 3
Registered: August 2015
Junior Member
I'm interested in this topic - but I couldn't find the relevant places to hook in the suggested methods.

Did the feature made it in the newer builds?
Could I get some more hints where to place the creation of the virtual diagram?
Previous Topic:Custom palette depending on diagram instance
Next Topic:Drawing a connection is not possible
Goto Forum:
  


Current Time: Tue Apr 16 15:39:35 GMT 2024

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

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

Back to the top