Home » Modeling » Graphiti » Saving only the domain model
| |
Re: Saving only the domain model [message #727613 is a reply to message #727442] |
Wed, 21 September 2011 16:14 |
Hernan Gonzalez Messages: 188 Registered: October 2010 Location: Buenos Aires, Argentina |
Senior Member |
|
|
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 10:17 |
Felix Velasco 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 |
Hernan Gonzalez Messages: 188 Registered: October 2010 Location: Buenos Aires, Argentina |
Senior Member |
|
|
Felix Velasco wrote on Thu, 22 September 2011 07:17There'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 #755757 is a reply to message #755486] |
Wed, 09 November 2011 14:01 |
Hernan Gonzalez Messages: 188 Registered: October 2010 Location: Buenos Aires, Argentina |
Senior Member |
|
|
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 10:11 |
Michael Wenz Messages: 1932 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
|
|
| | | |
Goto Forum:
Current Time: Fri Nov 08 23:30:57 GMT 2024
Powered by FUDForum. Page generated in 0.04574 seconds
|