Eclipse Community Forums: EMF » Problem saving GMF diagram in EMF resource.

Help

Home

Home » Modeling » EMF » Problem saving GMF diagram in EMF resource.

Show: Today's Messages :: Show Polls :: Message Navigator

Problem saving GMF diagram in EMF resource. [message #428756]

Sun, 29 March 2009 15:46

maatari

Messages: 74
Registered: July 2009

Member

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3321193611_1589232
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: 8bit

Hi all,

I

Report message to a moderator

Re: Problem saving GMF diagram in EMF resource. [message #428757 is a reply to message #428756]

Sun, 29 March 2009 16:01

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------090805090005040200010208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

M,

Comments below.

Daniel OKOUYA wrote:
> Hi all,
>
> I'm experiencing some issues to save a diagram in a ressource. Can
> someone help me understand a little bit better what happens when
> saving an Eobject in a resource? More specifically, how does it relate
> to workspaceModifyOperation?
It doesn't relate at all. Such an operation is just used to help group
a bunch of related workspace changes so that only a single set of
resource deltas is dispatched to any workspace listeners so, for
example, only a single build is kicked off.
> Currently, I have a multipage editor which follows the tutotrial on
> integrating EMF and GMF editor. My diagram(s) represent certain part
> of the model in the Tree. Meaning that at the difference to the
> tutorial, my diagram editor gets its input only after a click in the
> Selection Tree. However, I can't save anything from the diagram
> editor, only if I use properties (which is in fact a viewon its own).
> Meanwhile, changes made in both editor are reflected in both (The
> editing domain is well shared). Everything works fine, I just have
> this saving issue.
Are the changes you make undoable after you've done them. It sounds
like they aren't being executed on the command stack...
>
> Indeed, In my diagram editor, after looking at what was causing the
> problem I found that, the fCanBeSave variable attached to the
> ResourceInfo that the documents Provider obtain to check if a save is
> necessary, is always false when needed. Has it seams to be a resource
> issue, and because I'm a bit lost here, I was wondering if it might
> mean anything to anyone from an EMF point of view?
I think the GMF support for save is a bit different than the basic
support in EMF. I think the transaction APIs more carefully check which
specific files have changed. EMF's approach is to save all the files
because even if a file isn't directly changed, it might reference a
file that has changed and hence the fragment paths of those URIs might
have changed. If you can track the code that sets this variable you've
found and set breakpoints for a normal scenario where everything is
working, maybe that will help.

>
> Kind regards,
> M

--------------090805090005040200010208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
M, 
 
Comments below. 
 
Daniel OKOUYA wrote:
<blockquote cite="mid:C5F56488.9403%25okouya_d@yahoo.fr" type="cite">
<title>Problem saving GMF diagram in EMF resource. </title>
Hi all, 
 
I’m experiencing some issues to save a diagram in a ressource. Can
someone help me understand a little bit better what happens when saving
an Eobject in a resource? More specifically, how does it relate to
workspaceModifyOperation? 
</blockquote>
It doesn't relate at all.   Such an operation is just used to help
group a bunch of related workspace changes so that only a single set of
resource deltas is dispatched to any workspace listeners so, for
example, only a single build is kicked off. 
<blockquote cite="mid:C5F56488.9403%25okouya_d@yahoo.fr" type="cite">Currently, I have a multipage editor which
follows the tutotrial on integrating EMF and GMF editor. My diagram(s)
represent certain part of the model in the Tree. Meaning that at the
difference to the tutorial, my diagram editor gets its input only after
a click in the Selection Tree. However, I can’t save anything from the
 diagram editor, only if I use properties (which is in fact a viewon
its own). Meanwhile, changes made in both editor are reflected in both
(The editing domain is well shared). Everything works fine, I just have
this saving issue. 
</blockquote>
Are the changes you make undoable after you've done them.  It sounds
like they aren't being executed on the command stack... 
<blockquote cite="mid:C5F56488.9403%25okouya_d@yahoo.fr" type="cite"> 
Indeed, In my diagram editor, after looking at what was causing the
problem I found that, the fCanBeSave variable attached to the
ResourceInfo that  the documents Provider obtain to check if a save is
necessary, is always false when needed.  Has it seams to be a resource
issue, and because I’m a bit lost here, I was wondering if it might
mean anything to anyone from an EMF point of view? 
</blockquote>
I think the GMF support for save is a bit different than the basic
support in EMF. I think the transaction APIs more carefully check which
specific files have changed.   EMF's approach is to save all the files
because even if a file isn't directly changed,  it might reference a
file that has changed and hence the fragment paths of those URIs might
have changed.   If you can track the code that sets this variable
you've found and set breakpoints for a normal scenario where everything
is working, maybe that will help. 
 
<blockquote cite="mid:C5F56488.9403%25okouya_d@yahoo.fr" type="cite"> 
Kind regards, 
M
</blockquote>
</body>
</html>

--------------090805090005040200010208--

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Problem saving GMF diagram in EMF resource. [message #428758 is a reply to message #428757]

Sun, 29 March 2009 16:53

maatari

Messages: 74
Registered: July 2009

Member

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3321197587_1798951
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: 8bit

Thx for the reply.

>>>It doesn't relate at all. Such an operation is just used to help group a
bunch of related workspace changes so that only a single set of resource deltas
is dispatched to any workspace listeners so, for example, only a single build is
kicked off.
Therefore, what can it means to you to know that, if I remove the workspace
modify operation, I got Exception pointing at synchronization problem.

>>>>Are the changes you make undoable after you've done them. It sounds like
they aren't being executed on the command stack...

Yes the changes are undoable in both diagram and reflected correctly in both
diagram. However just for precision and I think it is normal when I make
change in in a diagram or in the tree the undo operation is available only
in the editor that did it.

>>>EMF's approach is to save all the files because even if a file isn't
directly changed, it might reference a file that has changed and hence the
fragment paths of those URIs might have changed
I did not really understand everything but that might explain why, the
variable which correspond to a diagram has its URI value changing each time
I do a save. In order to open my diagram, I

Report message to a moderator

Re: Problem saving GMF diagram in EMF resource. [message #428759 is a reply to message #428758]

Sun, 29 March 2009 16:59

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------020806040707010804050205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Daniel,

Comments below.

Daniel OKOUYA wrote:
> Thx for the reply.
>
>
> >>>It doesn't relate at all. Such an operation is just used to help
> group a bunch of related workspace changes so that only a single set
> of resource deltas is dispatched to any workspace listeners so, for
> example, only a single build is kicked off.
> Therefore, what can it means to you to know that, if I remove the
> workspace modify operation, I got Exception pointing at
> synchronization problem.
Likely it means that resource delta processing is kicking in too early,
i.e., immediately after you save one file rather than after you've saved
all the files.
>
> >>>>Are the changes you make undoable after you've done them. It
> sounds like they aren't being executed on the command stack...
>
> Yes the changes are undoable in both diagram and reflected correctly
> in both diagram. However just for precision and I think it is normal
> when I make change in in a diagram or in the tree the undo operation
> is available only in the editor that did it.
>
>
> >>>EMF's approach is to save all the files because even if a file
> isn't directly changed, it might reference a file that has changed
> and hence the fragment paths of those URIs might have changed
> I did not really understand everything but that might explain why, the
> variable which correspond to a diagram has its URI value changing each
> time I do a save.
I don't understand this variable changing URI thing at all.
> In order to open my diagram, I'm obliged to save the URI first
What does saving the URI mean?
> and then reuse it to open my editor.
I don't get this either.
> Because, if I use the URI of the diagram that has just been created, I
> will have a problem has it has change and it is pointing at the wrong
> place. What do you think?
That I'm totally confused.
> Just completeness, I do the creation of my diagram in a transactional
> command inside a workspaceModifyOperation. While I'm still in the
> operation, but have the command executed, the diagram variable and its
> URI are fine, once I quite the operation, the change happens.
So have you set breakpoints to track them down?
>
> Please let me know, if have any suggestion.
>
> Regards,
> Daniel
>
>
>
> On 3/29/09 6:01 PM, in article gqo61r$no$1@build.eclipse.org, "Ed
> Merks" <Ed.Merks@gmail.com> wrote:
>
> M,
>
> Comments below.
>
> Daniel OKOUYA wrote:
>
> Problem saving GMF diagram in EMF resource. Hi all,
>
> I'm experiencing some issues to save a diagram in a ressource.
> Can someone help me understand a little bit better what
> happens when saving an Eobject in a resource? More
> specifically, how does it relate to workspaceModifyOperation?
>
>
> It doesn't relate at all. Such an operation is just used to help
> group a bunch of related workspace changes so that only a single
> set of resource deltas is dispatched to any workspace listeners
> so, for example, only a single build is kicked off.
>
> Currently, I have a multipage editor which follows the
> tutotrial on integrating EMF and GMF editor. My diagram(s)
> represent certain part of the model in the Tree. Meaning that
> at the difference to the tutorial, my diagram editor gets its
> input only after a click in the Selection Tree. However, I
> can't save anything from the diagram editor, only if I use
> properties (which is in fact a viewon its own). Meanwhile,
> changes made in both editor are reflected in both (The editing
> domain is well shared). Everything works fine, I just have
> this saving issue.
>
>
> Are the changes you make undoable after you've done them. It
> sounds like they aren't being executed on the command stack...
>
>
> Indeed, In my diagram editor, after looking at what was
> causing the problem I found that, the fCanBeSave variable
> attached to the ResourceInfo that the documents Provider
> obtain to check if a save is necessary, is always false when
> needed. Has it seams to be a resource issue, and because I'm
> a bit lost here, I was wondering if it might mean anything to
> anyone from an EMF point of view?
>
>
> I think the GMF support for save is a bit different than the basic
> support in EMF. I think the transaction APIs more carefully check
> which specific files have changed. EMF's approach is to save all
> the files because even if a file isn't directly changed, it might
> reference a file that has changed and hence the fragment paths of
> those URIs might have changed. If you can track the code that
> sets this variable you've found and set breakpoints for a normal
> scenario where everything is working, maybe that will help.
>
>
> Kind regards,
> M
>
>

--------------020806040707010804050205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Daniel, 
 
Comments below. 
 
Daniel OKOUYA wrote:
<blockquote cite="mid:C5F5740F.9534%25okouya_d@yahoo.fr" type="cite">
<title>Re: Problem saving GMF diagram in EMF resource.</title>
Thx for the reply. 
 
 
>>>It doesn't relate at all.   Such an operation is just used
to help group a bunch of related workspace changes so that only a
single set of resource deltas is dispatched to any workspace listeners
so, for example, only a single build is kicked off. 
Therefore, what can it means to you to know that, if I remove the
workspace modify operation, I got Exception pointing at synchronization
problem. 
</blockquote>
Likely it means that resource delta processing is kicking in too
early,  i.e., immediately after you save one file rather than after
you've saved all the files. 
<blockquote cite="mid:C5F5740F.9534%25okouya_d@yahoo.fr" type="cite"> 
>>>>Are the changes you make undoable after you've done
them.  It sounds like they aren't being executed on the command stack... 
 
Yes the changes are undoable in both diagram and reflected correctly in
both diagram. However just for precision and I think it is normal when
I make change in in a diagram or in the tree the undo operation is
available only in the editor that did it. 
 
 
 >>>EMF's approach is to save all the files because even if a
file isn't directly changed,  it might reference a file that has
changed and hence the fragment paths of those URIs might have changed 
I did not really understand everything but that might explain why, the
variable which correspond to a diagram has its URI value changing each
time I do a save.</blockquote>
I don't understand this variable changing URI thing at all. 
<blockquote cite="mid:C5F5740F.9534%25okouya_d@yahoo.fr" type="cite"> In order to open my diagram, I’m obliged to
save the URI first</blockquote>
What does saving the URI mean? 
<blockquote cite="mid:C5F5740F.9534%25okouya_d@yahoo.fr" type="cite"> and then reuse it to open my editor.</blockquote>
I don't get this either. 
<blockquote cite="mid:C5F5740F.9534%25okouya_d@yahoo.fr" type="cite"> Because, if I use the URI of the diagram
that has just been created, I will have a problem has  it has change
and it is pointing at the wrong place. What do you think? 
</blockquote>
That I'm totally confused. 
<blockquote cite="mid:C5F5740F.9534%25okouya_d@yahoo.fr" type="cite">Just completeness, I do the creation of my
diagram in a transactional command inside a workspaceModifyOperation.
While I’m still in the operation, but have the command executed, the
diagram variable and its URI are fine, once I quite the operation, the
change happens. 
</blockquote>
So have you set breakpoints to track them down? 
<blockquote cite="mid:C5F5740F.9534%25okouya_d@yahoo.fr" type="cite"> 
Please let me know, if have any suggestion. 
 
Regards, 
Daniel 
 
 
 
On 3/29/09 6:01 PM, in article <a moz-do-not-send="true"
href="gqo61r$no$1@build.eclipse.org">gqo61r$no$1@build.eclipse.org</a>,
"Ed Merks" <<a moz-do-not-send="true" href="Ed.Merks@gmail.com">Ed.Merks@gmail.com</a>>
wrote: 
 

<blockquote>M, 
 
Comments below. 
 
Daniel OKOUYA wrote: 

<blockquote> Problem saving GMF diagram in EMF resource.
 Hi all, 
  
I’m experiencing some issues to save a diagram in a ressource. Can
someone help me understand a little bit better what happens when saving
an Eobject in a resource? More specifically, how does it relate to
workspaceModifyOperation? 
  
</blockquote>
It doesn't relate at all.   Such an operation
is just used to help group a bunch of related workspace changes so that
only a single set of resource deltas is dispatched to any workspace
listeners so, for example, only a single build is kicked off. 

<blockquote>Currently, I have a multipage editor which
follows the tutotrial on integrating EMF and GMF editor. My diagram(s)
represent certain part of the model in the Tree. Meaning that at the
difference to the tutorial, my diagram editor gets its input only after
a click in the Selection Tree. However, I can’t save anything from the
 diagram editor, only if I use properties (which is in fact a viewon
its own). Meanwhile, changes made in both editor are reflected in both
(The editing domain is well shared). Everything works fine, I just have
this saving issue. 
  
</blockquote>
Are the changes you make undoable after
you've done them.  It sounds like they aren't being executed on the
command stack... 

<blockquote> 
Indeed, In my diagram editor, after looking at what was causing the
problem I found that, the fCanBeSave variable attached to the
ResourceInfo that  the documents Provider obtain to check if a save is
necessary, is always false when needed.  Has it seams to be a resource
issue, and because I’m a bit lost here, I was wondering if it might
mean anything to anyone from an EMF point of view? 
  
</blockquote>
I think the GMF support for save is a bit
different than the basic support in EMF. I think the transaction APIs
more carefully check which specific files have changed.   EMF's
approach is to save all the files because even if a file isn't directly
changed,  it might reference a file that has changed and hence the
fragment paths of those URIs might have changed.   If you can track the
code that sets this variable you've found and set breakpoints for a
normal scenario where everything is working, maybe that will help. 
 

<blockquote> 
Kind regards, 
M 
</blockquote>
 
</blockquote>
</blockquote>
</body>
</html>

--------------020806040707010804050205--

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Problem saving GMF diagram in EMF resource. [message #428761 is a reply to message #428759]

Sun, 29 March 2009 17:50

maatari

Messages: 74
Registered: July 2009

Member

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3321201644_2061604
Content-type: multipart/alternative;
boundary="B_3321201644_2091064"

--B_3321201644_2091064
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: 8bit

It is difficult for me to track it. I did try all day long yesterday, but
give up, because, the change in the resource is happening during a period
which has nothing to do with my command. I have tried but it seams that it
is happening in another thread. It is only if I save, that the problem
appear. Please have a look at the java class file I send you and attached to
this post, it will definitively be more clear.

Kind regards,
-D-

On 3/29/09 6:59 PM, in article gqo9dq$dt0$1@build.eclipse.org, "Ed Merks"
<Ed.Merks@gmail.com> wrote:

> Daniel,
>
> Comments below.
>
> Daniel OKOUYA wrote:
>> Re: Problem saving GMF diagram in EMF resource. Thx for the reply.
>>
>>
>>>>> >>>It doesn't relate at all. Such an operation is just used to help
>>>>> group a bunch of related workspace changes so that only a single set of
>>>>> resource deltas is dispatched to any workspace listeners so, for example,
>>>>> only a single build is kicked off.
>> Therefore, what can it means to you to know that, if I remove the workspace
>> modify operation, I got Exception pointing at synchronization problem.
>>
> Likely it means that resource delta processing is kicking in too early, i.e.,
> immediately after you save one file rather than after you've saved all the
> files.
>>
>>>>>> >>>>Are the changes you make undoable after you've done them. It sounds
>>>>>> like they aren't being executed on the command stack...
>>
>> Yes the changes are undoable in both diagram and reflected correctly in both
>> diagram. However just for precision and I think it is normal when I make
>> change in in a diagram or in the tree the undo operation is available only in
>> the editor that did it.
>>
>>
>>>>> >>>EMF's approach is to save all the files because even if a file isn't
>>>>> directly changed, it might reference a file that has changed and hence
>>>>> the fragment paths of those URIs might have changed
>> I did not really understand everything but that might explain why, the
>> variable which correspond to a diagram has its URI value changing each time I
>> do a save.
> I don't understand this variable changing URI thing at all.
>> In order to open my diagram, I

Report message to a moderator

Re: Problem saving GMF diagram in EMF resource. [message #428762 is a reply to message #428759]

Sun, 29 March 2009 18:13

maatari

Messages: 74
Registered: July 2009

Member

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3321202393_2098283
Content-type: multipart/alternative;
boundary="B_3321202393_2144136"

--B_3321202393_2144136
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: 8bit

It is difficult for me to track it. I did try all day long yesterday, but
give up, because, the change in the resource is happening during a period
which has nothing to do with my command. I have tried but it seams that it
is happening in another thread. It is only if I save, that the problem
appear. Please have a look at the java class file I send you and attached to
this post, it will definitively be more clear.

Kind regards,
-D-

On 3/29/09 6:59 PM, in article gqo9dq$dt0$1@build.eclipse.org, "Ed Merks"
<Ed.Merks@gmail.com> wrote:

> Daniel,
>
> Comments below.
>
> Daniel OKOUYA wrote:
>> Re: Problem saving GMF diagram in EMF resource. Thx for the reply.
>>
>>
>>>>> >>>It doesn't relate at all. Such an operation is just used to help
>>>>> group a bunch of related workspace changes so that only a single set of
>>>>> resource deltas is dispatched to any workspace listeners so, for example,
>>>>> only a single build is kicked off.
>> Therefore, what can it means to you to know that, if I remove the workspace
>> modify operation, I got Exception pointing at synchronization problem.
>>
> Likely it means that resource delta processing is kicking in too early, i.e.,
> immediately after you save one file rather than after you've saved all the
> files.
>>
>>>>>> >>>>Are the changes you make undoable after you've done them. It sounds
>>>>>> like they aren't being executed on the command stack...
>>
>> Yes the changes are undoable in both diagram and reflected correctly in both
>> diagram. However just for precision and I think it is normal when I make
>> change in in a diagram or in the tree the undo operation is available only in
>> the editor that did it.
>>
>>
>>>>> >>>EMF's approach is to save all the files because even if a file isn't
>>>>> directly changed, it might reference a file that has changed and hence
>>>>> the fragment paths of those URIs might have changed
>> I did not really understand everything but that might explain why, the
>> variable which correspond to a diagram has its URI value changing each time I
>> do a save.
> I don't understand this variable changing URI thing at all.
>> In order to open my diagram, I

Report message to a moderator

Re: Problem saving GMF diagram in EMF resource. [message #428779 is a reply to message #428762]

Mon, 30 March 2009 10:38

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------010005010602060401030202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Daniel,

Comments below.

Daniel OKOUYA wrote:
> It is difficult for me to track it.
Even harder for me who can't run it at all and doesn't know GMF...
> I did try all day long yesterday, but give up, because, the change in
> the resource is happening during a period which has nothing to do with
> my command.
I wouldn't assume that.
> I have tried but it seams that it is happening in another thread.
That would be the resource delta processing that I've been talking
about. You make changes as part of a workspace modify operation and
then a background thread does the delta processing and the delta
notification.
> It is only if I save, that the problem appear. Please have a look at
> the java class file I send you and attached to this post, it will
> definitively be more clear.
Somehow you need to figure out why the processing of the resource delta
is causing a problem. In the EMF editor you'll notice that we have to
be quite careful that as part of save we record the resources we've
saved since we'll expect a resource delta for those resource. Normally
a resource delta on a resource in the resource set would prompt us to
unload the resource and reload it from the new contents, but obviously
when we've done a save ourselves, we don't want that to happen. Likely
your issues are related to this...
>
> Kind regards,
> -D-
>
> On 3/29/09 6:59 PM, in article gqo9dq$dt0$1@build.eclipse.org, "Ed
> Merks" <Ed.Merks@gmail.com> wrote:
>
> Daniel,
>
> Comments below.
>
> Daniel OKOUYA wrote:
>
> Re: Problem saving GMF diagram in EMF resource. Thx for the
> reply.
>
>
> >>>It doesn't relate at all. Such an operation is just used
> to help group a bunch of related workspace changes so that
> only a single set of resource deltas is dispatched to any
> workspace listeners so, for example, only a single build is
> kicked off.
> Therefore, what can it means to you to know that, if I remove
> the workspace modify operation, I got Exception pointing at
> synchronization problem.
>
>
> Likely it means that resource delta processing is kicking in too
> early, i.e., immediately after you save one file rather than
> after you've saved all the files.
>
>
> >>>>Are the changes you make undoable after you've done them.
> It sounds like they aren't being executed on the command stack...
>
> Yes the changes are undoable in both diagram and reflected
> correctly in both diagram. However just for precision and I
> think it is normal when I make change in in a diagram or in
> the tree the undo operation is available only in the editor
> that did it.
>
>
> >>>EMF's approach is to save all the files because even if a
> file isn't directly changed, it might reference a file that
> has changed and hence the fragment paths of those URIs might
> have changed
> I did not really understand everything but that might explain
> why, the variable which correspond to a diagram has its URI
> value changing each time I do a save.
>
> I don't understand this variable changing URI thing at all.
>
> In order to open my diagram, I'm obliged to save the URI first
>
> What does saving the URI mean?
>
> and then reuse it to open my editor.
>
> I don't get this either.
>
> Because, if I use the URI of the diagram that has just been
> created, I will have a problem has it has change and it is
> pointing at the wrong place. What do you think?
>
>
> That I'm totally confused.
>
> Just completeness, I do the creation of my diagram in a
> transactional command inside a workspaceModifyOperation. While
> I'm still in the operation, but have the command executed, the
> diagram variable and its URI are fine, once I quite the
> operation, the change happens.
>
>
> So have you set breakpoints to track them down?
>
>
> Please let me know, if have any suggestion.
>
> Regards,
> Daniel
>
>
>
> On 3/29/09 6:01 PM, in article gqo61r$no$1@build.eclipse.org,
> "Ed Merks" <Ed.Merks@gmail.com> wrote:
>
>
>
> M,
>
> Comments below.
>
> Daniel OKOUYA wrote:
>
>
> Problem saving GMF diagram in EMF resource. Hi all,
>
> I'm experiencing some issues to save a diagram in a
> ressource. Can someone help me understand a little bit
> better what happens when saving an Eobject in a
> resource? More specifically, how does it relate to
> workspaceModifyOperation?
>
>
>
> It doesn't relate at all. Such an operation is just used
> to help group a bunch of related workspace changes so that
> only a single set of resource deltas is dispatched to any
> workspace listeners so, for example, only a single build
> is kicked off.
>
>
> Currently, I have a multipage editor which follows the
> tutotrial on integrating EMF and GMF editor. My
> diagram(s) represent certain part of the model in the
> Tree. Meaning that at the difference to the tutorial,
> my diagram editor gets its input only after a click in
> the Selection Tree. However, I can't save anything
> from the diagram editor, only if I use properties
> (which is in fact a viewon its own). Meanwhile,
> changes made in both editor are reflected in both (The
> editing domain is well shared). Everything works fine,
> I just have this saving issue.
>
>
>
> Are the changes you make undoable after you've done them.
> It sounds like they aren't being executed on the command
> stack...
>
>
>
> Indeed, In my diagram editor, after looking at what
> was causing the problem I found that, the fCanBeSave
> variable attached to the ResourceInfo that the
> documents Provider obtain to check if a save is
> necessary, is always false when needed. Has it seams
> to be a resource issue, and because I'm a bit lost
> here, I was wondering if it might mean anything to
> anyone from an EMF point of view?
>
>
>
> I think the GMF support for save is a bit different than
> the basic support in EMF. I think the transaction APIs
> more carefully check which specific files have changed.
> EMF's approach is to save all the files because even if
> a file isn't directly changed, it might reference a file
> that has changed and hence the fragment paths of those
> URIs might have changed. If you can track the code that
> sets this variable you've found and set breakpoints for a
> normal scenario where everything is working, maybe that
> will help.
>
>
>
>
> Kind regards,
> M
>
>
>
>
>
>

--------------010005010602060401030202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Daniel, 
 
Comments below. 
 
Daniel OKOUYA wrote:
<blockquote cite="mid:C5F586D9.966B%25okouya_d@yahoo.fr" type="cite">
<title>Re: Problem saving GMF diagram in EMF resource.</title>
It is difficult for me to track it. </blockquote>
Even harder for me who can't run it at all and doesn't know GMF... 
<blockquote cite="mid:C5F586D9.966B%25okouya_d@yahoo.fr" type="cite">I did try all day long yesterday, but give
up, because, the change in the resource is happening during a period
which has nothing to do with my command.</blockquote>
I wouldn't assume that. 
<blockquote cite="mid:C5F586D9.966B%25okouya_d@yahoo.fr" type="cite"> I have tried but it seams that it is
happening in another thread.</blockquote>
That would be the resource delta processing that I've been talking
about.  You make changes as part of a workspace modify operation and
then a background thread does the delta processing and the delta
notification. 
<blockquote cite="mid:C5F586D9.966B%25okouya_d@yahoo.fr" type="cite"> It is only if I save, that the problem
appear. Please have a look at the java class file I send you and
attached to this post, it will definitively be more clear. 
</blockquote>
Somehow you need to figure out why the processing of the resource delta
is causing a problem.  In the EMF editor you'll notice that we have to
be quite careful that as part of save we record the resources we've
saved since we'll expect a resource delta for those resource.  Normally
a resource delta on a resource in the resource set would prompt us to
unload the resource and reload it from the new contents, but obviously
when we've done a save ourselves, we don't want that to happen.  Likely
your issues are related to this... 
<blockquote cite="mid:C5F586D9.966B%25okouya_d@yahoo.fr" type="cite"> 
Kind regards, 
-D- 
 
On 3/29/09 6:59 PM, in article <a moz-do-not-send="true"
href="gqo9dq$dt0$1@build.eclipse.org">gqo9dq$dt0$1@build.eclipse.org</a>,
"Ed Merks" <<a moz-do-not-send="true" href="Ed.Merks@gmail.com">Ed.Merks@gmail.com</a>>
wrote: 
 

<blockquote>Daniel, 
 
Comments below. 
 
Daniel OKOUYA wrote: 

<blockquote> Re: Problem saving GMF diagram in EMF
resource. Thx for the reply. 
  
  
>>>It doesn't relate at all.   Such an operation is just used
to help group a bunch of related workspace changes so that only a
single set of resource deltas is dispatched to any workspace listeners
so, for example, only a single build is kicked off. 
Therefore, what can it means to you to know that, if I remove the
workspace modify operation, I got Exception pointing at synchronization
problem. 
  
</blockquote>
Likely it means that resource delta
processing is kicking in too early,  i.e., immediately after you save
one file rather than after you've saved all the files. 

<blockquote> 
>>>>Are the changes you make undoable after you've done
them.  It sounds like they aren't being executed on the command stack... 
  
Yes the changes are undoable in both diagram and reflected correctly in
both diagram. However just for precision and I think it is normal when
I make change in in a diagram or in the tree the undo operation is
available only in the editor that did it. 
  
  
 >>>EMF's approach is to save all the files because even if a
file isn't directly changed,  it might reference a file that has
changed and hence the fragment paths of those URIs might have changed 
I did not really understand everything but that might explain why, the
variable which correspond to a diagram has its URI value changing each
time I do a save. 
</blockquote>
I don't understand this variable changing URI
thing at all. 

<blockquote> In order to open my diagram, I’m obliged to
save the URI first 
</blockquote>
What does saving the URI mean? 

<blockquote> and then reuse it to open my editor. 
</blockquote>
I don't get this either. 

<blockquote> Because, if I use the URI of the diagram
that has just been created, I will have a problem has  it has change
and it is pointing at the wrong place. What do you think? 
  
</blockquote>
That I'm totally confused. 

<blockquote>Just completeness, I do the creation of my
diagram in a transactional command inside a workspaceModifyOperation.
While I’m still in the operation, but have the command executed, the
diagram variable and its URI are fine, once I quite the operation, the
change happens. 
  
</blockquote>
So have you set breakpoints to track them
down? 

<blockquote> 
Please let me know, if have any suggestion. 
  
Regards, 
Daniel 
  
  
  
On 3/29/09 6:01 PM, in article <a moz-do-not-send="true"
href="gqo61r$no$1@build.eclipse.org">gqo61r$no$1@build.eclipse.org</a>,
"Ed Merks" <<a moz-do-not-send="true" href="Ed.Merks@gmail.com">Ed.Merks@gmail.com</a>>
wrote: 
  
   

<blockquote>M, 
  
Comments below. 
  
Daniel OKOUYA wrote: 
   

<blockquote> Problem saving GMF diagram in EMF resource.
 Hi all, 
  
I’m experiencing some issues to save a diagram in a ressource. Can
someone help me understand a little bit better what happens when saving
an Eobject in a resource? More specifically, how does it relate to
workspaceModifyOperation? 
  
  
</blockquote>
 It doesn't relate at all.   Such an
operation is just used to help group a bunch of related workspace
changes so that only a single set of resource deltas is dispatched to
any workspace listeners so, for example, only a single build is kicked
off. 
   

<blockquote>Currently, I have a multipage editor which
follows the tutotrial on integrating EMF and GMF editor. My diagram(s)
represent certain part of the model in the Tree. Meaning that at the
difference to the tutorial, my diagram editor gets its input only after
a click in the Selection Tree. However, I can’t save anything from the
 diagram editor, only if I use properties (which is in fact a viewon
its own). Meanwhile, changes made in both editor are reflected in both
(The editing domain is well shared). Everything works fine, I just have
this saving issue. 
  
  
</blockquote>
 Are the changes you make undoable after
you've done them.  It sounds like they aren't being executed on the
command stack... 
   

<blockquote> 
Indeed, In my diagram editor, after looking at what was causing the
problem I found that, the fCanBeSave variable attached to the
ResourceInfo that  the documents Provider obtain to check if a save is
necessary, is always false when needed.  Has it seams to be a resource
issue, and because I’m a bit lost here, I was wondering if it might
mean anything to anyone from an EMF point of view? 
  
  
</blockquote>
 I think the GMF support for save is a bit
different than the basic support in EMF. I think the transaction APIs
more carefully check which specific files have changed.   EMF's
approach is to save all the files because even if a file isn't directly
changed,  it might reference a file that has changed and hence the
fragment paths of those URIs might have changed.   If you can track the
code that sets this variable you've found and set breakpoints for a
normal scenario where everything is working, maybe that will help. 
  
   

<blockquote> 
Kind regards, 
M 
  
</blockquote>
 
  
</blockquote>
</blockquote>
 
</blockquote>
</blockquote>
</body>
</html>

--------------010005010602060401030202--

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Problem saving GMF diagram in EMF resource. [message #428796 is a reply to message #428779]

Mon, 30 March 2009 18:19

maatari

Messages: 74
Registered: July 2009

Member

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3321289164_1366050
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: 8bit

Hi ed.,
Thx for the reply. I will have a look at it right a way.

Meanwhile, for the sake of clarity for the post, here is the Class I
implemented following GMF-EMF tutorial to manage my try and hence creating
diagram when double clicked.

/**
* @author OKOUYA DANIEL MAATARI
*
*/
public class OperaSelectionTreeEditorPart extends AbstractOperaEditorPart {

public static final String ID =
"opera.presentation.OperaSelectionTreeEditorID"; //$NON-NLS-1$

protected TreeViewer viewer = null;
private Diagram newDiagram = null;
private URI diagURUI = null;
private boolean newCreation = false;

public OperaSelectionTreeEditorPart(OperaEditor parentEditor) {
super(parentEditor);
}

@Override
public void setInput(Object input) {
viewer.setInput(input);
}

public TreeViewer getViewer () {
return viewer;
}

@Override
public void setFocus() {
viewer.getTree().setFocus();
}

@Override
public void createPartControl(Composite parent) {
viewer = new TreeViewer(parent, SWT.MULTI);
viewer.setContentProvider(new
AdapterFactoryContentProvider(getAdapterFactory()));
viewer.setLabelProvider(new
AdapterFactoryLabelProvider(getAdapterFactory()));
addDiagOpeningDblClickListener();
viewer.setSelection(new
StructuredSelection(getEditingDomain().getResourceSet().getR esources().get(0
)), true);
getEditorSite().setSelectionProvider(viewer);
new AdapterFactoryTreeEditor(viewer.getTree(), getAdapterFactory());
createContextMenuFor(viewer);
}

/**
* @author OKOUYA DANIEL MAATARI
*
* The double click Listener which open diagram
*
*/
protected void addDiagOpeningDblClickListener() {

viewer.addDoubleClickListener(new IDoubleClickListener () {

public void doubleClick(final
DoubleClickEvent event) {

if (!event.getSelection().isEmpty()) {

IStructuredSelection selection =
(IStructuredSelection) event.getSelection();
final Object object =
selection.getFirstElement();

if (object instanceof EObject && (
((EObject)object).eClass() == OMPackage.Literals.SS ||
((EObject)object).eClass() == OMPackage.Literals.IS) ) {

Iterator<Setting> it =
getNonNavigableInverse(NotationPackage.Literals.DIAGRAM, null,
(EObject)object, ((EObject)object).eResource());
newDiagram = null;
diagURUI = null;
newCreation = false;

if (!it.hasNext())

CreateDiagWithWorkSpaceMonitoring((EObject) object);
else {
newDiagram = (Diagram)
it.next().getEObject();
diagURUI =
EcoreUtil.getURI(newDiagram);
}
openNewDiagram();

}

}

}
});

}

/**
*@author OKOUYA DANIEL MAATARI
*
*Open the New diagram in his corresponding Editor.
*To find the correct Editor to open, Eclass of the element associated
to the diagram
*is checked first
*
*
* @param diagram
*/
private void openNewDiagram() {

int pageIndex = 0;
EClass eclass =
newDiagram.getElement().eClass();
DiagramDocumentEditor diagramEditor = (eclass ==
OMPackage.Literals.SS ? new OperADiagramEditor() : eclass ==
OMPackage.Literals.IS ? new OperAISDiagramEditor() : null);

if (ActivateEditorforDiag())
return;

try {

pageIndex = parentEditor.addPage(diagramEditor,

parentEditor.getWrappedInput(new URIEditorInput(diagURUI)));
}
catch (PartInitException e) {
OperAEditorPlugin.INSTANCE.log(e);
}

parentEditor.setPageText(pageIndex, eclass == OMPackage.Literals.SS
? "social structure" : eclass == OMPackage.Literals.IS ? "Interaction
Structure" : null);
parentEditor.setActiveEditor(diagramEditor);
parentEditor.showTabs();
}

/**
* @author OKOUYA DANIEL MAATARI
* Create A new Diagram for the object passed as parameter
*
* @param object
* @return Diagram
* @throws Exception
*/
private void createNewdiagram(final EObject object, IProgressMonitor
monitor) throws Exception {
List<Object> affectedFiles = new LinkedList<Object>();
String path = EcoreUtil.getURI(object).toPlatformString(true);

IResource workspaceResource =
ResourcesPlugin.getWorkspace().getRoot()
.findMember(new Path(path));
affectedFiles.add(workspaceResource);

AbstractTransactionalCommand command =
new AbstractTransactionalCommand ((TransactionalEditingDomain)
getEditingDomain(), "Diagram Opening", affectedFiles)
{
@Override
protected CommandResult doExecuteWithResult(IProgressMonitor
monitor, IAdaptable info)
throws ExecutionException {
monitor.beginTask("Diagram Creation", 10);
newDiagram = ViewService.createDiagram(
object,
object.eClass() ==
OMPackage.Literals.SS ? SSEditPart.MODEL_ID : object.eClass() ==
OMPackage.Literals.IS ? ISEditPart.MODEL_ID : null,
object.eClass() ==
OMPackage.Literals.SS ? OperADiagramEditorPlugin.DIAGRAM_PREFERENCES_HINT :
object.eClass() == OMPackage.Literals.IS ?
OperAISDiagramEditorPlugin.DIAGRAM_PREFERENCES_HINT : null);
object.eResource().getContents().add(newDiagram);

//newDiagram.setElement(object);
newDiagram.setName(object.eClass() == OMPackage.Literals.SS
? "Social Structure" : "Interaction Structure");

try {

newDiagram.eResource().save(OperADiagramEditorUtil.getSaveOp tions());
} catch (IOException e) {
OperAEditorPlugin.INSTANCE.log(e);
e.printStackTrace();
}
diagURUI = EcoreUtil.getURI(newDiagram);

return CommandResult.newOKCommandResult();
}

};

OperationHistoryFactory.getOperationHistory().execute(comman d, new
SubProgressMonitor(monitor, 1), null);
newCreation = true;

return;
}

/**
*
* @author OKOUYA DANIEL MAATARI
*
* @param object: this is the object for which we create the new diagram
* @return
*/
private void CreateDiagWithWorkSpaceMonitoring(final EObject object) {

try {
IRunnableWithProgress op = new WorkspaceModifyOperation() {

@Override
protected void execute(IProgressMonitor monitor) throws
CoreException, InvocationTargetException,
InterruptedException {

try {
createNewdiagram(object, monitor);
}

catch (InvocationTargetException e) {
if (e.getTargetException() instanceof CoreException)
{
ErrorDialog.openError(getSite().getShell(),

Messages.OperACreationWizardCreationError, null,
((CoreException)
e.getTargetException()).getStatus());
} else {
OperADiagramEditorPlugin.getInstance().logError(

"Error creating diagram", e.getTargetException()); //$NON-NLS-1$
}
}
catch (Exception e) {

OperAEditorPlugin.INSTANCE.log(e);
}
}
};

new
ProgressMonitorDialog(parentEditor.getSite().getShell()).run (true, false,
op);
} catch (Exception e) {

OperAEditorPlugin.INSTANCE.log(e);
}
return;
}

/**
*
* @author OKOUYA DANIEL MAATARI
*
* Search for an editor that contain the newDiagram (in this case it is
not a new one but a retrieved one)
*
* @return
*/
private IEditorPart findOpenedEditorforDiag() {

int count = parentEditor.getPageCount();

for (int i = 1; i < count; i++) {
IEditorPart ed = parentEditor.getEditor(i);
if (ed instanceof DiagramEditor) {
if (((DiagramDocumentEditor)
ed).getDiagram().getName().equals(newDiagram.getName())) {
return ed;
};
}
}
return null;
}

/**
*
* @author OKOUYA DANIEL MAATARI
*
* Activate the Editor that already contain the newDiagram
*
* @return boolean
*/
private boolean ActivateEditorforDiag() {
IEditorPart ed = null;

if (!newCreation && (ed = findOpenedEditorforDiag()) != null)
{
parentEditor.setActiveEditor(ed);
return true;
}
return false;
}

/**
* @author OKOUYA DANIEL MAATARI
*
* Return all the non Navigable inverse Reference on the object
*
* @param eClass
* @param reference
* @param object
* @param context
* @return Iterator<Setting>
*/
public static Iterator<Setting> getNonNavigableInverse(EClass eClass,
EReference reference, EObject object, Notifier context)
{
ECrossReferenceAdapter adapter =
ECrossReferenceAdapter.getCrossReferenceAdapter(context);
if (adapter == null) {
adapter = new ECrossReferenceAdapter();
context.eAdapters().add(adapter);
}
return new
EcoreUtil.FilteredSettingsIterator(adapter.getNonNavigableIn verseReferences(
object, true), reference, eClass);
}
}

Kind regards,
Daniel

On 3/30/09 12:38 PM, in article gqq7g5$7um$1@build.eclipse.org, "Ed Merks"
<Ed.Merks@gmail.com> wrote:

> Daniel,
>
> Comments below.
>
> Daniel OKOUYA wrote:
>> Re: Problem saving GMF diagram in EMF resource. It is difficult for me to
>> track it.
> Even harder for me who can't run it at all and doesn't know GMF...
>> I did try all day long yesterday, but give up, because, the change in the
>> resource is happening during a period which has nothing to do with my
>> command.
> I wouldn't assume that.
>> I have tried but it seams that it is happening in another thread.
> That would be the resource delta processing that I've been talking about. You
> make changes as part of a workspace modify operation and then a background
> thread does the delta processing and the delta notification.
>> It is only if I save, that the problem appear. Please have a look at the
>> java class file I send you and attached to this post, it will definitively be
>> more clear.
>>
> Somehow you need to figure out why the processing of the resource delta is
> causing a problem. In the EMF editor you'll notice that we have to be quite
> careful that as part of save we record the resources we've saved since we'll
> expect a resource delta for those resource. Normally a resource delta on a
> resource in the resource set would prompt us to unload the resource and reload
> it from the new contents, but obviously when we've done a save ourselves, we
> don't want that to happen. Likely your issues are related to this...
>>
>> Kind regards,
>> -D-
>>
>> On 3/29/09 6:59 PM, in article gqo9dq$dt0$1@build.eclipse.org, "Ed Merks"
>> <Ed.Merks@gmail.com> wrote:
>>
>>
>>> Daniel,
>>>
>>> Comments below.
>>>
>>> Daniel OKOUYA wrote:
>>>
>>>> Re: Problem saving GMF diagram in EMF resource. Thx for the reply.
>>>>
>>>>
>>>>>>> >>>It doesn't relate at all. Such an operation is just used to help
>>>>>>> group a bunch of related workspace changes so that only a single set of
>>>>>>> resource deltas is dispatched to any workspace listeners so, for
>>>>>>> example, only a single build is kicked off.
>>>> Therefore, what can it means to you to know that, if I remove the workspace
>>>> modify operation, I got Exception pointing at synchronization problem.
>>>>
>>>>
>>> Likely it means that resource delta processing is kicking in too early,
>>> i.e., immediately after you save one file rather than after you've saved all
>>> the files.
>>>
>>>>
>>>>>>>> >>>>Are the changes you make undoable after you've done them. It
>>>>>>>> sounds like they aren't being executed on the command stack...
>>>>
>>>> Yes the changes are undoable in both diagram and reflected correctly in
>>>> both diagram. However just for precision and I think it is normal when I
>>>> make change in in a diagram or in the tree the undo operation is available
>>>> only in the editor that did it.
>>>>
>>>>
>>>>>>> >>>EMF's approach is to save all the files because even if a file isn't
>>>>>>> directly changed, it might reference a file that has changed and hence
>>>>>>> the fragment paths of those URIs might have changed
>>>> I did not really understand everything but that might explain why, the
>>>> variable which correspond to a diagram has its URI value changing each time
>>>> I do a save.
>>>>
>>> I don't understand this variable changing URI thing at all.
>>>
>>>> In order to open my diagram, I

Report message to a moderator

Previous Topic:	[CDO] setup-workspace.prop update for M6
Next Topic:	EPackage Implementation to EPAckage Class

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 26 03:37:43 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter