Home » Modeling » EMF » Resources and in-memory models
| | |
| Re: Resources and in-memory models [message #420676 is a reply to message #420674] |
Mon, 07 July 2008 12:44   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080202020303010003090502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Alan,
Comments below.
Alan wrote:
> Hi Ed,
>
> I hear tell that you're gardening time has been greatly increased just
> recently so I don't feel too bad about cutting into it :-)
>
It's a fact! I'm on two weeks of vacation now, and after that, I'm
unemployed and headed for a sailing ship cruise from Quebec to Newfoundland.
> On your points -
> Yes we are using a SharedEditingDomain
>
> Undoing eveything since last save - funny you should mention it because that
> is the route we have been going for a while.
> We specialised the OperationHistory and added a OneTimeCommand called
> SavePlaceHolder which as the name suggests acts as a marker on the history
> as to when an editor was saved.
> On a save we add the SavePlaceHolder (with correct context)
> On a close do not save we roll back the undo stack until we hit the save
> marker.
>
> And everything seemed to be going fine until -
>
Darn! :-P
> Scenario :
> - Add an object
> - Save
> - Undo
>
> Now close and do not save means we look at the undo stack but there is
> nothing there in front of the SavePlaceHolder as the operation is now on the
> Redo stack.
>
It sounds a bit like you should either being undoing or redoing to get
the stack back to the same place of the stack where the save happened.
> So I updated the code to add SavePlaceHolders to the Redo stack also and
> redo the ops there on a close don't save
>
> Again seemed to be working fine until:
>
> Scenario:
> - Add an object
> - Save
> - Delete object
> - Undo
>
> Now there is something on the redo stack but we should not redo it as both
> ops done since the save cancel each other out.
>
> So the question is how do I know if an op on the redo stack should be redone
> ?
>
In BasicCommandStack itself, there is a saveIndex that keeps track of
the index in the command list when save last was done. I imagine you
should either be undoing or redoing command get get the top to match the
save index.
> In other words was the op undone before or after the save.
> The first thing that came to mind was something with timestamps and
> comparing times on the SavePlaceHolder on the undo stack with the redoable
> op on the redo stack.
>
> Anyway it was at that point that I started to question the whole approach as
> it seemed to be getting scary.
>
I don't know enough about some of the extended frameworks in terms of
the save placeholders, but it seems to me you should determine in which
direction you need to go to get to the placeholder; I'm not sure if
there are APIs for that... From a BasicCommandStack point of view it
makes me think there should be perhaps a "revert" method that reverts
the model to the last save location since internally, all the knowledge
is available...
> So there you have it....any comments welcome as always
>
> I'm off to mow the lawn as I'm fairly sure how that works !! :-)
>
Don't run over any frogs!
>
> thanks,
> Alan.
>
>
> "Ed Merks" <Ed.Merks@gmail.com> wrote in message
> news:g4lhs4$6nq$1@build.eclipse.org...
>
>> Alan,
>>
>> Comments below.
>>
>> Alan wrote:
>>
>>> Hello all,
>>>
>>> I will do my best to explain the problem we are having but its late on a
>>> Friday so bear with me.
>>>
>>>
>> It's only just noon for me, but you're starting to cut into my garden
>> time. :-P
>>
>>> Ok we have a shared model which contains references to objects from other
>>> models.
>>> So the shared model contains an interface IMSharedObject which is
>>> implemented by model objects that need to be shared.
>>>
>>> The issue we are having is when closing the editors of the models whose
>>> objects are shared.
>>>
>>> So we have two editors
>>> 1) Shared model editor which shows all shared objects from all models
>>> 2) A graphical (GMF) editor for a specific domain model some of whose
>>> objects are shared
>>>
>>>
>> I wonder if you're using a shared editing domain...
>>
>>> Scenario
>>> 1 - We add object a and b to GMF editor.
>>> 2 - Object a and b appear in shared editor
>>> 3 - We save the GMF editor
>>> 4 - We delete object a.
>>> 5 - The shared editor no longer shows object a
>>> 6 - We now close the GMF editor and choose not to save
>>> 7 - The shared editor should show object a again as the deletion was
>>> effectively cancelled but at the moment it does not.
>>>
>>>
>> Not so effectively canceled was it. :-P I suppose one approach would be
>> to have the GMF editor undo every it did since the last save...
>>
>>> When we add objects to the shared model we call an add method on it and
>>> likewise a remove for deletions.
>>> However as the editor is closing we the GMF editor does not get a chance
>>> to call the shared model method to add/remove.
>>> The correct contents of the GMF editor are stored in its semantic model
>>> but it does not inform the shared model of this.
>>>
>>> My question is how do I get around this ?
>>>
>>> We tried a couple of things such as recording transactions run on the
>>> editor that affect shared data sinxce it was saved and rolling these back
>>> but its very complex and doesn't feel right so we think there must be
>>> another way.
>>>
>>>
>> Given that you second editor is sharing state with the first editor, if
>> you really want closing the second editor to undo changes, I think you
>> need to focus on an approach that undoes all the changes during close.
>>
>>> Is the resource the key here ?
>>> I mean effectively what we need to do is synch the in-memory reference to
>>> the model with the saved version of it.
>>>
>>> Any comments welcome
>>>
>>>
>>> thanks,
>>> Alan.
>>>
>>>
>>>
>>>
>
>
>
--------------080202020303010003090502
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">
Alan,<br>
<br>
Comments below.<br>
<br>
Alan wrote:
<blockquote cite="mid:g4t14e$mni$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Ed,
I hear tell that you're gardening time has been greatly increased just
recently so I don't feel too bad about cutting into it :-)
</pre>
</blockquote>
It's a fact! I'm on two weeks of vacation now, and after that, I'm
unemployed and headed for a sailing ship cruise from Quebec to
Newfoundland.<br>
<blockquote cite="mid:g4t14e$mni$1@build.eclipse.org" type="cite">
<pre wrap="">
On your points -
Yes we are using a SharedEditingDomain
Undoing eveything since last save - funny you should mention it because that
is the route we have been going for a while.
We specialised the OperationHistory and added a OneTimeCommand called
SavePlaceHolder which as the name suggests acts as a marker on the history
as to when an editor was saved.
On a save we add the SavePlaceHolder (with correct context)
On a close do not save we roll back the undo stack until we hit the save
marker.
And everything seemed to be going fine until -
</pre>
</blockquote>
Darn! :-P<br>
<blockquote cite="mid:g4t14e$mni$1@build.eclipse.org" type="cite">
<pre wrap="">
Scenario :
- Add an object
- Save
- Undo
Now close and do not save means we look at the undo stack but there is
nothing there in front of the SavePlaceHolder as the operation is now on the
Redo stack.
</pre>
</blockquote>
It sounds a bit like you should either being undoing or redoing to get
the stack back to the same place of the stack where the save happened.<br>
<blockquote cite="mid:g4t14e$mni$1@build.eclipse.org" type="cite">
<pre wrap="">So I updated the code to add SavePlaceHolders to the Redo stack also and
redo the ops there on a close don't save
Again seemed to be working fine until:
Scenario:
- Add an object
- Save
- Delete object
- Undo
Now there is something on the redo stack but we should not redo it as both
ops done since the save cancel each other out.
So the question is how do I know if an op on the redo stack should be redone
?
</pre>
</blockquote>
In BasicCommandStack itself, there is a saveIndex that keeps track of
the index in the command list when save last was done. I imagine you
should either be undoing or redoing command get get the top to match
the save index.<br>
<blockquote cite="mid:g4t14e$mni$1@build.eclipse.org" type="cite">
<pre wrap="">In other words was the op undone before or after the save.
The first thing that came to mind was something with timestamps and
comparing times on the SavePlaceHolder on the undo stack with the redoable
op on the redo stack.
Anyway it was at that point that I started to question the whole approach as
it seemed to be getting scary.
</pre>
</blockquote>
I don't know enough about some of the extended frameworks in terms of
the save placeholders, but it seems to me you should determine in which
direction you need to go to get to the placeholder; I'm not sure if
there are APIs for that... From a BasicCommandStack point of view it
makes me think there should be perhaps a "revert" method that reverts
the model to the last save location since internally, all the knowledge
is available...<br>
<blockquote cite="mid:g4t14e$mni$1@build.eclipse.org" type="cite">
<pre wrap="">
So there you have it....any comments welcome as always
I'm off to mow the lawn as I'm fairly sure how that works !! :-)
</pre>
</blockquote>
Don't run over any frogs!<br>
<blockquote cite="mid:g4t14e$mni$1@build.eclipse.org" type="cite">
<pre wrap="">
thanks,
Alan.
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:g4lhs4$6nq$1@build.eclipse.org">news:g4lhs4$6nq$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Alan,
Comments below.
Alan wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello all,
I will do my best to explain the problem we are having but its late on a
Friday so bear with me.
</pre>
</blockquote>
<pre wrap="">It's only just noon for me, but you're starting to cut into my garden
time. :-P
</pre>
<blockquote type="cite">
<pre wrap="">Ok we have a shared model which contains references to objects from other
models.
So the shared model contains an interface IMSharedObject which is
implemented by model objects that need to be shared.
The issue we are having is when closing the editors of the models whose
objects are shared.
So we have two editors
1) Shared model editor which shows all shared objects from all models
2) A graphical (GMF) editor for a specific domain model some of whose
objects are shared
</pre>
</blockquote>
<pre wrap="">I wonder if you're using a shared editing domain...
</pre>
<blockquote type="cite">
<pre wrap="">Scenario
1 - We add object a and b to GMF editor.
2 - Object a and b appear in shared editor
3 - We save the GMF editor
4 - We delete object a.
5 - The shared editor no longer shows object a
6 - We now close the GMF editor and choose not to save
7 - The shared editor should show object a again as the deletion was
effectively cancelled but at the moment it does not.
</pre>
</blockquote>
<pre wrap="">Not so effectively canceled was it. :-P I suppose one approach would be
to have the GMF editor undo every it did since the last save...
</pre>
<blockquote type="cite">
<pre wrap="">When we add objects to the shared model we call an add method on it and
likewise a remove for deletions.
However as the editor is closing we the GMF editor does not get a chance
to call the shared model method to add/remove.
The correct contents of the GMF editor are stored in its semantic model
but it does not inform the shared model of this.
My question is how do I get around this ?
We tried a couple of things such as recording transactions run on the
editor that affect shared data sinxce it was saved and rolling these back
but its very complex and doesn't feel right so we think there must be
another way.
</pre>
</blockquote>
<pre wrap="">Given that you second editor is sharing state with the first editor, if
you really want closing the second editor to undo changes, I think you
need to focus on an approach that undoes all the changes during close.
</pre>
<blockquote type="cite">
<pre wrap="">Is the resource the key here ?
I mean effectively what we need to do is synch the in-memory reference to
the model with the saved version of it.
Any comments welcome
thanks,
Alan.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
--------------080202020303010003090502--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Resources and in-memory models [message #420680 is a reply to message #420676] |
Mon, 07 July 2008 15:07 |
Alan
Messages: 44
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000F_01C8E04B.8279F9A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
"headed for a sailing ship cruise from Quebec to Newfoundland."
Now thats depressing me. While I'm hear struggling with the EMF plumbing =
you'll be off doing that :-)
"In BasicCommandStack itself, there is a saveIndex that keeps track of =
the index in the command list when save last was done. I imagine you =
should either be undoing or redoing command get get the top to match the =
save index."
Interesting point. I went and had a look at BasicCommandStack and the =
index looks like it could help in what we are trying to do.
However we currently use the IOperationHistory as opposed to the =
BasicCommandStack. The OperationHistory seems to work with two =
arraylists to represent the undo and redo stacks seperately and so there =
isn't the same index.
So I looked into the BasicCommandStack hierarchy and there is a =
WorkspaceCommandStackImpl which takes an IOperationHistory in its =
constructor which looks interesting.
So I think I'll see if we can switch to using the =
WorkspaceCommandStackImpl and try and use that index you mention to help =
me
thanks a lot for the help
Alan.
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:g4t334$gtk$1@build.eclipse.org...
Alan,
Comments below.
Alan wrote:=20
Hi Ed,
I hear tell that you're gardening time has been greatly increased just=20
recently so I don't feel too bad about cutting into it :-)
It's a fact! I'm on two weeks of vacation now, and after that, I'm =
unemployed and headed for a sailing ship cruise from Quebec to =
Newfoundland.
On your points -
Yes we are using a SharedEditingDomain
Undoing eveything since last save - funny you should mention it because =
that=20
is the route we have been going for a while.
We specialised the OperationHistory and added a OneTimeCommand called=20
SavePlaceHolder which as the name suggests acts as a marker on the =
history=20
as to when an editor was saved.
On a save we add the SavePlaceHolder (with correct context)
On a close do not save we roll back the undo stack until we hit the save =
marker.
And everything seemed to be going fine until -
Darn! :-P
Scenario :
- Add an object
- Save
- Undo
Now close and do not save means we look at the undo stack but there is=20
nothing there in front of the SavePlaceHolder as the operation is now on =
the=20
Redo stack.
It sounds a bit like you should either being undoing or redoing to get =
the stack back to the same place of the stack where the save happened.
So I updated the code to add SavePlaceHolders to the Redo stack also and =
redo the ops there on a close don't save
Again seemed to be working fine until:
Scenario:
- Add an object
- Save
- Delete object
- Undo
Now there is something on the redo stack but we should not redo it as =
both=20
ops done since the save cancel each other out.
So the question is how do I know if an op on the redo stack should be =
redone=20
?
In BasicCommandStack itself, there is a saveIndex that keeps track of =
the index in the command list when save last was done. I imagine you =
should either be undoing or redoing command get get the top to match the =
save index.
In other words was the op undone before or after the save.
The first thing that came to mind was something with timestamps and=20
comparing times on the SavePlaceHolder on the undo stack with the =
redoable=20
op on the redo stack.
Anyway it was at that point that I started to question the whole =
approach as=20
it seemed to be getting scary.
I don't know enough about some of the extended frameworks in terms of =
the save placeholders, but it seems to me you should determine in which =
direction you need to go to get to the placeholder; I'm not sure if =
there are APIs for that... From a BasicCommandStack point of view it =
makes me think there should be perhaps a "revert" method that reverts =
the model to the last save location since internally, all the knowledge =
is available...
So there you have it....any comments welcome as always
I'm off to mow the lawn as I'm fairly sure how that works !! :-)
Don't run over any frogs!
thanks,
Alan.
"Ed Merks" <Ed.Merks@gmail.com> wrote in message=20
news:g4lhs4$6nq$1@build.eclipse.org...
Alan,
Comments below.
Alan wrote:
Hello all,
I will do my best to explain the problem we are having but its late on a =
Friday so bear with me.
It's only just noon for me, but you're starting to cut into my =
garden=20
time. :-P
Ok we have a shared model which contains references to objects from =
other=20
models.
So the shared model contains an interface IMSharedObject which is=20
implemented by model objects that need to be shared.
The issue we are having is when closing the editors of the models whose=20
objects are shared.
So we have two editors
1) Shared model editor which shows all shared objects from all models
2) A graphical (GMF) editor for a specific domain model some of whose=20
objects are shared
I wonder if you're using a shared editing domain...
Scenario
1 - We add object a and b to GMF editor.
2 - Object a and b appear in shared editor
3 - We save the GMF editor
4 - We delete object a.
5 - The shared editor no longer shows object a
6 - We now close the GMF editor and choose not to save
7 - The shared editor should show object a again as the deletion was=20
effectively cancelled but at the moment it does not.
Not so effectively canceled was it. :-P I suppose one approach =
would be=20
to have the GMF editor undo every it did since the last save...
When we add objects to the shared model we call an add method on it =
and=20
likewise a remove for deletions.
However as the editor is closing we the GMF editor does not get a chance =
to call the shared model method to add/remove.
The correct contents of the GMF editor are stored in its semantic model=20
but it does not inform the shared model of this.
My question is how do I get around this ?
We tried a couple of things such as recording transactions run on the=20
editor that affect shared data sinxce it was saved and rolling these =
back=20
but its very complex and doesn't feel right so we think there must be=20
another way.
Given that you second editor is sharing state with the first =
editor, if=20
you really want closing the second editor to undo changes, I think you=20
need to focus on an approach that undoes all the changes during close.
Is the resource the key here ?
I mean effectively what we need to do is synch the in-memory reference =
to=20
the model with the saved version of it.
Any comments welcome
thanks,
Alan.
=20
------=_NextPart_000_000F_01C8E04B.8279F9A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.6000.16674" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV>"headed for a sailing ship cruise from Quebec to =
Newfoundland."</DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Now thats depressing me. While I'm hear =
struggling=20
with the EMF plumbing you'll be off doing that :-)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>"<FONT face=3D"Times New Roman" =
size=3D3>In=20
BasicCommandStack itself, there is a saveIndex that keeps track of the =
index in=20
the command list when save last was done. I imagine you should =
either be=20
undoing or redoing command get get the top to match the save=20
index."</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Interesting point. I went and had a =
look at=20
BasicCommandStack and the index looks like it could help in what we are =
trying=20
to do.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>However we currently use the =
IOperationHistory as=20
opposed to the BasicCommandStack. The OperationHistory seems to work =
with two=20
arraylists to represent the undo and redo stacks seperately and so there =
isn't=20
the same index.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>So I looked into the BasicCommandStack =
hierarchy=20
and there is a WorkspaceCommandStackImpl which takes an =
IOperationHistory in its=20
constructor which looks interesting.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So I think I'll see if we can switch to =
using the=20
WorkspaceCommandStackImpl and try and use that index you mention to help =
me</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>thanks a lot for the help</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Alan.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>"Ed Merks" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote in =
message <A=20
href=3D"news:g4t334$gtk$1@build.eclipse.org">news:g4t334$gtk$1@build.ecli=
pse.org</A>...</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">Alan,<BR><BR>Comments =
below.<BR><BR>Alan wrote:=20
<BLOCKQUOTE cite=3Dmid:g4t14e$mni$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Hi Ed,
I hear tell that you're gardening time has been greatly increased just=20
recently so I don't feel too bad about cutting into it :-)
</PRE></BLOCKQUOTE>It's a fact! I'm on two weeks of vacation =
now, and=20
after that, I'm unemployed and headed for a sailing ship cruise from =
Quebec to=20
Newfoundland.<BR>
<BLOCKQUOTE cite=3Dmid:g4t14e$mni$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">On your points -
Yes we are using a SharedEditingDomain
Undoing eveything since last save - funny you should mention it because =
that=20
is the route we have been going for a while.
We specialised the OperationHistory and added a OneTimeCommand called=20
SavePlaceHolder which as the name suggests acts as a marker on the =
history=20
as to when an editor was saved.
On a save we add the SavePlaceHolder (with correct context)
On a close do not save we roll back the undo stack until we hit the save =
marker.
And everything seemed to be going fine until -
</PRE></BLOCKQUOTE>Darn! :-P<BR>
<BLOCKQUOTE cite=3Dmid:g4t14e$mni$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Scenario :
- Add an object
- Save
- Undo
Now close and do not save means we look at the undo stack but there is=20
nothing there in front of the SavePlaceHolder as the operation is now on =
the=20
Redo stack.
</PRE></BLOCKQUOTE>It sounds a bit like you should either being =
undoing or=20
redoing to get the stack back to the same place of the stack where the =
save=20
happened.<BR>
<BLOCKQUOTE cite=3Dmid:g4t14e$mni$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">So I updated the code to add =
SavePlaceHolders to the Redo stack also and=20
redo the ops there on a close don't save
Again seemed to be working fine until:
Scenario:
- Add an object
- Save
- Delete object
- Undo
Now there is something on the redo stack but we should not redo it as =
both=20
ops done since the save cancel each other out.
So the question is how do I know if an op on the redo stack should be =
redone=20
?
</PRE></BLOCKQUOTE>In BasicCommandStack itself, there is a saveIndex =
that=20
keeps track of the index in the command list when save last was =
done. I=20
imagine you should either be undoing or redoing command get get the =
top to=20
match the save index.<BR>
<BLOCKQUOTE cite=3Dmid:g4t14e$mni$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">In other words was the op undone before or =
after the save.
The first thing that came to mind was something with timestamps and=20
comparing times on the SavePlaceHolder on the undo stack with the =
redoable=20
op on the redo stack.
Anyway it was at that point that I started to question the whole =
approach as=20
it seemed to be getting scary.
</PRE></BLOCKQUOTE>I don't know enough about some of the extended =
frameworks=20
in terms of the save placeholders, but it seems to me you should =
determine in=20
which direction you need to go to get to the placeholder; I'm not sure =
if=20
there are APIs for that... From a BasicCommandStack point of =
view it=20
makes me think there should be perhaps a "revert" method that reverts =
the=20
model to the last save location since internally, all the knowledge is =
available...<BR>
<BLOCKQUOTE cite=3Dmid:g4t14e$mni$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">So there you have it....any comments =
welcome as always
I'm off to mow the lawn as I'm fairly sure how that works !! :-)
</PRE></BLOCKQUOTE>Don't run over any frogs!<BR>
<BLOCKQUOTE cite=3Dmid:g4t14e$mni$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">
thanks,
Alan.
"Ed Merks" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></A> wrote =
in message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:g4lhs4$6nq$1@build.eclipse.org">news:g4lhs4$6nq$1@build.ecli=
pse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Alan,
Comments below.
Alan wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hello all,
I will do my best to explain the problem we are having but its late on a =
Friday so bear with me.
</PRE></BLOCKQUOTE><PRE wrap=3D"">It's only just noon for me, but =
you're starting to cut into my garden=20
time. :-P
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Ok we have a shared model =
which contains references to objects from other=20
models.
So the shared model contains an interface IMSharedObject which is=20
implemented by model objects that need to be shared.
The issue we are having is when closing the editors of the models whose=20
objects are shared.
So we have two editors
1) Shared model editor which shows all shared objects from all models
2) A graphical (GMF) editor for a specific domain model some of whose=20
objects are shared
</PRE></BLOCKQUOTE><PRE wrap=3D"">I wonder if you're using a =
shared editing domain...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Scenario
1 - We add object a and b to GMF editor.
2 - Object a and b appear in shared editor
3 - We save the GMF editor
4 - We delete object a.
5 - The shared editor no longer shows object a
6 - We now close the GMF editor and choose not to save
7 - The shared editor should show object a again as the deletion was=20
effectively cancelled but at the moment it does not.
</PRE></BLOCKQUOTE><PRE wrap=3D"">Not so effectively canceled was =
it. :-P I suppose one approach would be=20
to have the GMF editor undo every it did since the last save...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">When we add objects to =
the shared model we call an add method on it and=20
likewise a remove for deletions.
However as the editor is closing we the GMF editor does not get a chance =
to call the shared model method to add/remove.
The correct contents of the GMF editor are stored in its semantic model=20
but it does not inform the shared model of this.
My question is how do I get around this ?
We tried a couple of things such as recording transactions run on the=20
editor that affect shared data sinxce it was saved and rolling these =
back=20
but its very complex and doesn't feel right so we think there must be=20
another way.
</PRE></BLOCKQUOTE><PRE wrap=3D"">Given that you second editor is =
sharing state with the first editor, if=20
you really want closing the second editor to undo changes, I think you=20
need to focus on an approach that undoes all the changes during close.
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Is the resource the key =
here ?
I mean effectively what we need to do is synch the in-memory reference =
to=20
the model with the saved version of it.
Any comments welcome
thanks,
Alan.
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->
</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_000F_01C8E04B.8279F9A0--
|
|
|
| Re: Resources and in-memory models [message #420682 is a reply to message #420680] |
Mon, 07 July 2008 15:50 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030702060708030909090601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Alan,
Comments below.
Alan wrote:
> "headed for a sailing ship cruise from Quebec to Newfoundland."
>
> Now thats depressing me. While I'm hear struggling with the EMF
> plumbing you'll be off doing that :-)
We each make our own choices in life. :-P
>
>
> "In BasicCommandStack itself, there is a saveIndex that keeps track of
> the index in the command list when save last was done. I imagine you
> should either be undoing or redoing command get get the top to match
> the save index."
>
> Interesting point. I went and had a look at BasicCommandStack and the
> index looks like it could help in what we are trying to do.
> However we currently use the IOperationHistory as opposed to the
> BasicCommandStack. The OperationHistory seems to work with two
> arraylists to represent the undo and redo stacks seperately and so
> there isn't the same index.
>
> So I looked into the BasicCommandStack hierarchy and there is a
> WorkspaceCommandStackImpl which takes an IOperationHistory in its
> constructor which looks interesting.
> So I think I'll see if we can switch to using the
> WorkspaceCommandStackImpl and try and use that index you mention to
> help me
I wonder if I should provide a "revert" method on CommandStack itself so
there'd be an API way to undoing/redoing to the last save point... I'm
not sure how that would affect the higher level abstractions build on
top though...
>
> thanks a lot for the help
Don't take it personally. I help everyone just the same. Hehehe. :-P
>
> Alan.
>
>
>
>
> "Ed Merks" <Ed.Merks@gmail.com <mailto:Ed.Merks@gmail.com>> wrote in
> message news:g4t334$gtk$1@build.eclipse.org...
>
> Alan,
>
> Comments below.
>
> Alan wrote:
>> Hi Ed,
>>
>> I hear tell that you're gardening time has been greatly increased just
>> recently so I don't feel too bad about cutting into it :-)
>>
> It's a fact! I'm on two weeks of vacation now, and after that,
> I'm unemployed and headed for a sailing ship cruise from Quebec to
> Newfoundland.
>> On your points -
>> Yes we are using a SharedEditingDomain
>>
>> Undoing eveything since last save - funny you should mention it because that
>> is the route we have been going for a while.
>> We specialised the OperationHistory and added a OneTimeCommand called
>> SavePlaceHolder which as the name suggests acts as a marker on the history
>> as to when an editor was saved.
>> On a save we add the SavePlaceHolder (with correct context)
>> On a close do not save we roll back the undo stack until we hit the save
>> marker.
>>
>> And everything seemed to be going fine until -
>>
> Darn! :-P
>> Scenario :
>> - Add an object
>> - Save
>> - Undo
>>
>> Now close and do not save means we look at the undo stack but there is
>> nothing there in front of the SavePlaceHolder as the operation is now on the
>> Redo stack.
>>
> It sounds a bit like you should either being undoing or redoing to
> get the stack back to the same place of the stack where the save
> happened.
>> So I updated the code to add SavePlaceHolders to the Redo stack also and
>> redo the ops there on a close don't save
>>
>> Again seemed to be working fine until:
>>
>> Scenario:
>> - Add an object
>> - Save
>> - Delete object
>> - Undo
>>
>> Now there is something on the redo stack but we should not redo it as both
>> ops done since the save cancel each other out.
>>
>> So the question is how do I know if an op on the redo stack should be redone
>> ?
>>
> In BasicCommandStack itself, there is a saveIndex that keeps track
> of the index in the command list when save last was done. I
> imagine you should either be undoing or redoing command get get
> the top to match the save index.
>> In other words was the op undone before or after the save.
>> The first thing that came to mind was something with timestamps and
>> comparing times on the SavePlaceHolder on the undo stack with the redoable
>> op on the redo stack.
>>
>> Anyway it was at that point that I started to question the whole approach as
>> it seemed to be getting scary.
>>
> I don't know enough about some of the extended frameworks in terms
> of the save placeholders, but it seems to me you should determine
> in which direction you need to go to get to the placeholder; I'm
> not sure if there are APIs for that... From a BasicCommandStack
> point of view it makes me think there should be perhaps a "revert"
> method that reverts the model to the last save location since
> internally, all the knowledge is available...
>> So there you have it....any comments welcome as always
>>
>> I'm off to mow the lawn as I'm fairly sure how that works !! :-)
>>
> Don't run over any frogs!
>> thanks,
>> Alan.
>>
>>
>> "Ed Merks" <Ed.Merks@gmail.com> wrote in message
>> news:g4lhs4$6nq$1@build.eclipse.org...
>>
>>> Alan,
>>>
>>> Comments below.
>>>
>>> Alan wrote:
>>>
>>>> Hello all,
>>>>
>>>> I will do my best to explain the problem we are having but its late on a
>>>> Friday so bear with me.
>>>>
>>>>
>>> It's only just noon for me, but you're starting to cut into my garden
>>> time. :-P
>>>
>>>> Ok we have a shared model which contains references to objects from other
>>>> models.
>>>> So the shared model contains an interface IMSharedObject which is
>>>> implemented by model objects that need to be shared.
>>>>
>>>> The issue we are having is when closing the editors of the models whose
>>>> objects are shared.
>>>>
>>>> So we have two editors
>>>> 1) Shared model editor which shows all shared objects from all models
>>>> 2) A graphical (GMF) editor for a specific domain model some of whose
>>>> objects are shared
>>>>
>>>>
>>> I wonder if you're using a shared editing domain...
>>>
>>>> Scenario
>>>> 1 - We add object a and b to GMF editor.
>>>> 2 - Object a and b appear in shared editor
>>>> 3 - We save the GMF editor
>>>> 4 - We delete object a.
>>>> 5 - The shared editor no longer shows object a
>>>> 6 - We now close the GMF editor and choose not to save
>>>> 7 - The shared editor should show object a again as the deletion was
>>>> effectively cancelled but at the moment it does not.
>>>>
>>>>
>>> Not so effectively canceled was it. :-P I suppose one approach would be
>>> to have the GMF editor undo every it did since the last save...
>>>
>>>> When we add objects to the shared model we call an add method on it and
>>>> likewise a remove for deletions.
>>>> However as the editor is closing we the GMF editor does not get a chance
>>>> to call the shared model method to add/remove.
>>>> The correct contents of the GMF editor are stored in its semantic model
>>>> but it does not inform the shared model of this.
>>>>
>>>> My question is how do I get around this ?
>>>>
>>>> We tried a couple of things such as recording transactions run on the
>>>> editor that affect shared data sinxce it was saved and rolling these back
>>>> but its very complex and doesn't feel right so we think there must be
>>>> another way.
>>>>
>>>>
>>> Given that you second editor is sharing state with the first editor, if
>>> you really want closing the second editor to undo changes, I think you
>>> need to focus on an approach that undoes all the changes during close.
>>>
>>>> Is the resource the key here ?
>>>> I mean effectively what we need to do is synch the in-memory reference to
>>>> the model with the saved version of it.
>>>>
>>>> Any comments welcome
>>>>
>>>>
>>>> thanks,
>>>> Alan.
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
--------------030702060708030909090601
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">
Alan,<br>
<br>
Comments below.<br>
<br>
Alan wrote:
<blockquote cite="mid:g4tbf1$ht3$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.6000.16674" name="GENERATOR">
<style></style>
<div>"headed for a sailing ship cruise from Quebec to Newfoundland."</div>
<div> </div>
<div><font face="Arial" size="2">Now thats depressing me. While I'm
hear struggling with the EMF plumbing you'll be off doing that :-)</font></div>
</blockquote>
We each make our own choices in life. :-P<br>
<blockquote cite="mid:g4tbf1$ht3$1@build.eclipse.org" type="cite">
<div> </div>
<div> </div>
<div><font face="Arial" size="2">"<font face="Times New Roman"
size="3">In BasicCommandStack itself, there is a saveIndex that keeps
track of the index in the command list when save last was done. I
imagine you should either be undoing or redoing command get get the top
to match the save index."</font></font></div>
<div> </div>
<div><font face="Arial" size="2">Interesting point. I went and had a
look at BasicCommandStack and the index looks like it could help in
what we are trying to do.</font></div>
<div><font face="Arial" size="2">However we currently use the
IOperationHistory as opposed to the BasicCommandStack. The
OperationHistory seems to work with two arraylists to represent the
undo and redo stacks seperately and so there isn't the same index.</font></div>
<div> </div>
<div><font face="Arial" size="2">So I looked into the
BasicCommandStack hierarchy and there is a WorkspaceCommandStackImpl
which takes an IOperationHistory in its constructor which looks
interesting.</font></div>
<div><font face="Arial" size="2">So I think I'll see if we can switch
to using the WorkspaceCommandStackImpl and try and use that index you
mention to help me</font></div>
</blockquote>
I wonder if I should provide a "revert" method on CommandStack itself
so there'd be an API way to undoing/redoing to the last save point...
I'm not sure how that would affect the higher level abstractions build
on top though...<br>
<blockquote cite="mid:g4tbf1$ht3$1@build.eclipse.org" type="cite">
<div> </div>
<div><font face="Arial" size="2">thanks a lot for the help</font></div>
</blockquote>
Don't take it personally. I help everyone just the same. Hehehe. :-P<br>
<blockquote cite="mid:g4tbf1$ht3$1@build.eclipse.org" type="cite">
<div> </div>
<div><font face="Arial" size="2">Alan.</font></div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div>"Ed Merks" <<a moz-do-not-send="true"
href="mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</a>> wrote in
message <a moz-do-not-send="true"
href="news:g4t334$gtk$1@build.eclipse.org">news:g4t334$gtk$1@build.eclipse.org</a>...</div>
<blockquote dir="ltr"
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">Alan,<br>
<br>
Comments below.<br>
<br>
Alan wrote:
<blockquote cite="mid:g4t14e$mni$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Ed,
I hear tell that you're gardening time has been greatly increased just
recently so I don't feel too bad about cutting into it :-)
</pre>
</blockquote>
It's a fact! I'm on two weeks of vacation now, and after that, I'm
unemployed and headed for a sailing ship cruise from Quebec to
Newfoundland.<br>
<blockquote cite="mid:g4t14e$mni$1@build.eclipse.org" type="cite">
<pre wrap="">On your points -
Yes we are using a SharedEditingDomain
Undoing eveything since last save - funny you should mention it because that
is the route we have been going for a while.
We specialised the OperationHistory and added a OneTimeCommand called
SavePlaceHolder which as the name suggests acts as a marker on the history
as to when an editor was saved.
On a save we add the SavePlaceHolder (with correct context)
On a close do not save we roll back the undo stack until we hit the save
marker.
And everything seemed to be going fine until -
</pre>
</blockquote>
Darn! :-P<br>
<blockquote cite="mid:g4t14e$mni$1@build.eclipse.org" type="cite">
<pre wrap="">Scenario :
- Add an object
- Save
- Undo
Now close and do not save means we look at the undo stack but there is
nothing there in front of the SavePlaceHolder as the operation is now on the
Redo stack.
</pre>
</blockquote>
It sounds a bit like you should either being undoing or redoing to get
the stack back to the same place of the stack where the save happened.<br>
<blockquote cite="mid:g4t14e$mni$1@build.eclipse.org" type="cite">
<pre wrap="">So I updated the code to add SavePlaceHolders to the Redo stack also and
redo the ops there on a close don't save
Again seemed to be working fine until:
Scenario:
- Add an object
- Save
- Delete object
- Undo
Now there is something on the redo stack but we should not redo it as both
ops done since the save cancel each other out.
So the question is how do I know if an op on the redo stack should be redone
?
</pre>
</blockquote>
In BasicCommandStack itself, there is a saveIndex that keeps track of
the index in the command list when save last was done. I imagine you
should either be undoing or redoing command get get the top to match
the save index.<br>
<blockquote cite="mid:g4t14e$mni$1@build.eclipse.org" type="cite">
<pre wrap="">In other words was the op undone before or after the save.
The first thing that came to mind was something with timestamps and
comparing times on the SavePlaceHolder on the undo stack with the redoable
op on the redo stack.
Anyway it was at that point that I started to question the whole approach as
it seemed to be getting scary.
</pre>
</blockquote>
I don't know enough about some of the extended frameworks in terms of
the save placeholders, but it seems to me you should determine in which
direction you need to go to get to the placeholder; I'm not sure if
there are APIs for that... From a BasicCommandStack point of view it
makes me think there should be perhaps a "revert" method that reverts
the model to the last save location since internally, all the knowledge
is available...<br>
<blockquote cite="mid:g4t14e$mni$1@build.eclipse.org" type="cite">
<pre wrap="">So there you have it....any comments welcome as always
I'm off to mow the lawn as I'm fairly sure how that works !! :-)
</pre>
</blockquote>
Don't run over any frogs!<br>
<blockquote cite="mid:g4t14e$mni$1@build.eclipse.org" type="cite">
<pre wrap="">thanks,
Alan.
"Ed Merks" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></a> wrote in message
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="news:g4lhs4$6nq$1@build.eclipse.org">news:g4lhs4$6nq$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Alan,
Comments below.
Alan wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello all,
I will do my best to explain the problem we are having but its late on a
Friday so bear with me.
</pre>
</blockquote>
<pre wrap="">It's only just noon for me, but you're starting to cut into my garden
time. :-P
</pre>
<blockquote type="cite">
<pre wrap="">Ok we have a shared model which contains references to objects from other
models.
So the shared model contains an interface IMSharedObject which is
implemented by model objects that need to be shared.
The issue we are having is when closing the editors of the models whose
objects are shared.
So we have two editors
1) Shared model editor which shows all shared objects from all models
2) A graphical (GMF) editor for a specific domain model some of whose
objects are shared
</pre>
</blockquote>
<pre wrap="">I wonder if you're using a shared editing domain...
</pre>
<blockquote type="cite">
<pre wrap="">Scenario
1 - We add object a and b to GMF editor.
2 - Object a and b appear in shared editor
3 - We save the GMF editor
4 - We delete object a.
5 - The shared editor no longer shows object a
6 - We now close the GMF editor and choose not to save
7 - The shared editor should show object a again as the deletion was
effectively cancelled but at the moment it does not.
</pre>
</blockquote>
<pre wrap="">Not so effectively canceled was it. :-P I suppose one approach would be
to have the GMF editor undo every it did since the last save...
</pre>
<blockquote type="cite">
<pre wrap="">When we add objects to the shared model we call an add method on it and
likewise a remove for deletions.
However as the editor is closing we the GMF editor does not get a chance
to call the shared model method to add/remove.
The correct contents of the GMF editor are stored in its semantic model
but it does not inform the shared model of this.
My question is how do I get around this ?
We tried a couple of things such as recording transactions run on the
editor that affect shared data sinxce it was saved and rolling these back
but its very complex and doesn't feel right so we think there must be
another way.
</pre>
</blockquote>
<pre wrap="">Given that you second editor is sharing state with the first editor, if
you really want closing the second editor to undo changes, I think you
need to focus on an approach that undoes all the changes during close.
</pre>
<blockquote type="cite">
<pre wrap="">Is the resource the key here ?
I mean effectively what we need to do is synch the in-memory reference to
the model with the saved version of it.
Any comments welcome
thanks,
Alan.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------030702060708030909090601--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 12:15:50 GMT 2024
Powered by FUDForum. Page generated in 0.04365 seconds |
] 
Search
Help
Register
Login
Home
