Visual ID and graceful migration? [message #117530] |
Thu, 05 April 2007 22:47 |
Eclipse User |
|
|
|
Originally posted by: khai.n.situvista.com
I have a fairly robust GMF editor for a large XML Schema/EMF model that
is already being used by the client to create artifacts; the model and
editor are going through enhancement iterations, and the model and
diagram are in separate files.
Adding new elements to the XML Schema is pretty straight-forward and the
newly generated EMF code can open and manipulate older model files
without conflicts and without having to implement migration logic.
When it comes to the diagram files I find that I will have to implement
manual conversion from one version to another when new elements are
added to the editor or else the new editor can not load older diagram
files. This is because of a few things:
1. The diagram file stores the View ID as the 'type' for a node
2. The View ID is generated by the "Create generator model..." process
where it generates and stores the View ID for each node in the .gmfgen
file
3. Under 'certain' condition when new elements are added through .gmfmap
the View ID's are regenerated and some existing nodes are given a
different View ID.
Simplified example: An existing diagram with a Link Mapping 'A' with
View ID = 4000, a new node 'B' is added through .gmfmap , the generator
then gives 'A' a new View ID of 4001 and the new node 'B' the View ID of
4000. Clearly this would mean that any previously created diagram file
is no longer consistent and therefore can not be loaded with the new
editor.
Current Work-around:
1. Manually 'reassign' View ID through editing .gmfgen before generating
diagram code (this is tedious and error-prone because it has to be done
manually each time something changes in .gmfgraph/.gmfmap)
2. Re-init the diagram from the model file (this is a viable option for
simple models but the model I have is location-sensitive to where each
element is in relation to others on the canvas; and that information is
stored in the .diagram file which I can no longer load therefore the
diagram files would have to be converted before opening)
3. Manually convert the older .diagram files through raw text editing
(we all know how error-prone this can be)
Questions:
Is there a setting to tell the generator to NOT assign new View ID to
existing nodes?
Is there a specific order to add new elements to .gmfgraph/.gmfmap to
ensure that existing View ID are not changed?
Thanks in advance for any helpful hints
-- Khai --
|
|
|
|
Re: Visual ID and graceful migration? [message #117666 is a reply to message #117585] |
Fri, 06 April 2007 20:13 |
Eclipse User |
|
|
|
Originally posted by: khai.n.situvista.com
Thanks for the pointer, Alex, this seems like a viable long-term
solution which I will look into integrating into my workflow.
Unfortunately, for now, I can not integrate an 'experimental'
plug-in because the client wants to work with API's that are
relatively guaranteed to not change between minor updates:-(
Well it looks like custom code for now and potentially using the
....trace capabilities in the long run.
Thanks again for the help.
-- Khai --
Alex Shatalin wrote:
> Hello Khai,
>
> Proposed solution for now is to install org.eclipse.gmf.bridge.trace
> plugin (part of sdk.experimental distribution). This plugin will create
> additional ..trace file during .gmfmap -> .gmfgen transformation and
> will use it to dispatch visualIDs on next transformation. You can easily
> modify this file in case of some complex changes, but for the situations
> like: new mapping was added/removed default .trace file should be
> sufficient.
>
> Known problem: on first .gmfmap -> .gmfgen transformation all the
> visualIDs will be changes due to the different logic used in
> bridge.trace I suggest you to perform this transformation, re-generate
> the code and re-create all the diagrams. This is only one migration
> which should be done. Mostly all the following .gmfmap mode
> modifications should be automatically processed by trace plugin.
>
> -----------------
> Alex Shatalin
>
>
>
|
|
|
|
Re: Visual ID and graceful migration? [message #203412 is a reply to message #117585] |
Tue, 26 August 2008 14:57 |
Eclipse User |
|
|
|
Originally posted by: michael.wohlfart.proceedinnovation.com
Alex Shatalin schrieb:
> Hello Khai,
>
> Proposed solution for now is to install org.eclipse.gmf.bridge.trace
> plugin (part of sdk.experimental distribution). This plugin will create
> additional .trace file during .gmfmap -> .gmfgen transformation and will
> use it to dispatch visualIDs on next transformation. You can easily
> modify this file in case of some complex changes, but for the situations
> like: new mapping was added/removed default .trace file should be
> sufficient.
>
> Known problem: on first .gmfmap -> .gmfgen transformation all the
> visualIDs will be changes due to the different logic used in
> bridge.trace I suggest you to perform this transformation, re-generate
> the code and re-create all the diagrams. This is only one migration
> which should be done. Mostly all the following .gmfmap mode
> modifications should be automatically processed by trace plugin.
>
> -----------------
> Alex Shatalin
>
Hello!
I have the same problem Khai had more than a year ago. I made sure I had
installed the .trace plugin, but the .trace files are not showing up in
the project.
Do I have to enable the generation of these files somewhere, or am I
just searching in the wrong place?
Maybe worth mentioning, I'm still using GMF 2.0.1.. migration is planned
til end of year...
Greetings,
Michael Wohlfart
|
|
|
|
Powered by
FUDForum. Page generated in 0.02910 seconds