Home » Modeling » Graphiti » Saving only the domain model
Saving only the domain model [message #726907] |
Mon, 19 September 2011 17:43  |
Eclipse User |
|
|
|
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 #727613 is a reply to message #727442] |
Wed, 21 September 2011 12:14   |
Eclipse User |
|
|
|
Felix Velasco wrote on Wed, 21 September 2011 07:15We'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 06:17   |
Eclipse User |
|
|
|
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 #755757 is a reply to message #755486] |
Wed, 09 November 2011 09:01   |
Eclipse User |
|
|
|
buschcobolt wrote on Tue, 08 November 2011 13:11hey 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 05:11   |
Eclipse User |
|
|
|
"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 #1709359 is a reply to message #726907] |
Sun, 27 September 2015 14:36  |
Eclipse User |
|
|
|
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?
|
|
|
Goto Forum:
Current Time: Sat Apr 26 08:40:57 EDT 2025
Powered by FUDForum. Page generated in 0.03955 seconds
|