Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EMF Edit - can additional operations happen when a command happens?
EMF Edit - can additional operations happen when a command happens? [message #1046945] Mon, 22 April 2013 15:29 Go to next message
Ben Cox is currently offline Ben CoxFriend
Messages: 17
Registered: June 2012
Junior Member
I have a form-based editor, backed by EMF using the EMF Edit databindings. The editor's dirty state and undo/redo are all linked into the EditingDomain's dirty flag - all good.

The editor modifies a number of files, which aren't linked in an EMF-aware manner. For example, in one file a reference is made to a particular object name, which is also referred to in another file.

I'd like it to be the case that, when I modify the object name in a Text box, it changes in both places.

Is the best way of doing this to have two bindings registered, both with the Text as target but different EMFEdit observables in the background? Or is there another way, whereby changing the value in the binding also triggers a change in the other place? I would use Adapters, but I'm not sure they fit into the EditingDomain's view of things - is that correct?
Re: EMF Edit - can additional operations happen when a command happens? [message #1046972 is a reply to message #1046945] Mon, 22 April 2013 16:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33107
Registered: July 2009
Senior Member
Ben,

Comments below.

On 22/04/2013 5:30 PM, Ben Cox wrote:
> I have a form-based editor, backed by EMF using the EMF Edit
> databindings. The editor's dirty state and undo/redo are all linked
> into the EditingDomain's dirty flag - all good.
>
> The editor modifies a number of files, which aren't linked in an
> EMF-aware manner.
The editor modifying files seems bad in and of itself. One generally
expects and editor to make to changes to the underlying storage except
when you save. So if you close a dirty editor, any changes you made
should have no impact...
> For example, in one file a reference is made to a particular object
> name, which is also referred to in another file.
>
> I'd like it to be the case that, when I modify the object name in a
> Text box, it changes in both places.
So you're really modifying other files and "saving" those changes?
>
> Is the best way of doing this to have two bindings registered, both
> with the Text as target but different EMFEdit observables in the
> background?
Probably, if it's all just in-memory changes.
> Or is there another way, whereby changing the value in the binding
> also triggers a change in the other place? I would use Adapters, but
> I'm not sure they fit into the EditingDomain's view of things - is
> that correct?
All the views supported directly by EMF.Edit using adapters so that's
fine too.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF Edit - can additional operations happen when a command happens? [message #1047021 is a reply to message #1046972] Mon, 22 April 2013 17:27 Go to previous messageGo to next message
Ben Cox is currently offline Ben CoxFriend
Messages: 17
Registered: June 2012
Junior Member
Hi Ed,

Thanks for your speedy response. Comments below.


Quote:
On 22/04/2013 5:30 PM, Ben Cox wrote:
> I have a form-based editor, backed by EMF using the EMF Edit
> databindings. The editor's dirty state and undo/redo are all linked
> into the EditingDomain's dirty flag - all good.
>
> The editor modifies a number of files, which aren't linked in an
> EMF-aware manner.
The editor modifying files seems bad in and of itself. One generally
expects and editor to make to changes to the underlying storage except
when you save. So if you close a dirty editor, any changes you made
should have no impact...


Sorry, perhaps I wasn't clear. To clarify, the editor only makes changes to the files when a save is requested. The point I was trying to highlight was that the editor takes input from, and will save to, a number of files - much like the PDE Manifest Editor, which uses MANIFEST.MF, plugin.xml and build.properties.

Quote:
> For example, in one file a reference is made to a particular object
> name, which is also referred to in another file.
>
> I'd like it to be the case that, when I modify the object name in a
> Text box, it changes in both places.
So you're really modifying other files and "saving" those changes?


Err... maybe?

Quote:
> Is the best way of doing this to have two bindings registered, both
> with the Text as target but different EMFEdit observables in the
> background?
Probably, if it's all just in-memory changes.
> Or is there another way, whereby changing the value in the binding
> also triggers a change in the other place? I would use Adapters, but
> I'm not sure they fit into the EditingDomain's view of things - is
> that correct?
All the views supported directly by EMF.Edit using adapters so that's
fine too.

I will try to find some solution that involves either a number of bindings or adapters. I just want to ensure that the additional changes caused by that change are seen by the EditingDomain, and are added to the same step on the command stack.
Re: EMF Edit - can additional operations happen when a command happens? [message #1047172 is a reply to message #1047021] Mon, 22 April 2013 22:10 Go to previous messageGo to next message
Ben Cox is currently offline Ben CoxFriend
Messages: 17
Registered: June 2012
Junior Member
Right, well having more than one databinding doesn't work - we get stuck in a horrible situation such that, however many commands are on the command stack, repeating the Undo command just cycles between the previous state and the current state, instead of going further back into the history.

Nor does the Adapter way of going about it seem to help - unless I somehow get the adding/removal of Adapters put into the command history too.

Yours,
Stuck!
Re: EMF Edit - can additional operations happen when a command happens? [message #1047363 is a reply to message #1047172] Tue, 23 April 2013 05:32 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33107
Registered: July 2009
Senior Member
Ben,

It's not clear what the various approaching are doing... Adapters
normally just respond to changes by updating a view. They should not
update the state of the model; that should be done only with commands.
It sounds more as if you should be specializing the one command to do
several things which you'd normally do by specializing what the "normal"
command does in the item generated provider.


On 23/04/2013 12:10 AM, Ben Cox wrote:
> Right, well having more than one databinding doesn't work - we get
> stuck in a horrible situation such that, however many commands are on
> the command stack, repeating the Undo command just cycles between the
> previous state and the current state, instead of going further back
> into the history.
>
> Nor does the Adapter way of going about it seem to help - unless I
> somehow get the adding/removal of Adapters put into the command
> history too.
>
> Yours,
> Stuck!


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF Edit - can additional operations happen when a command happens? [message #1047395 is a reply to message #1047363] Tue, 23 April 2013 06:40 Go to previous messageGo to next message
Ben Cox is currently offline Ben CoxFriend
Messages: 17
Registered: June 2012
Junior Member
Hi Ed,

Quote:
It's not clear what the various approaching are doing... Adapters
normally just respond to changes by updating a view. They should not
update the state of the model; that should be done only with commands.

That's good to know!

It sounds more as if you should be specializing the one command to do 
several things which you'd normally do by specializing what the "normal" 
command does in the item generated provider.

Aha - overriding the createSetCommand methods from ItemProviderAdapter to create a compound command instead of the simple SetCommand? It's the first time I've seen those methods - sounds like a good idea!
Re: EMF Edit - can additional operations happen when a command happens? [message #1047401 is a reply to message #1047395] Tue, 23 April 2013 06:46 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33107
Registered: July 2009
Senior Member
Ben,

Yes, the item providers act as a command factory, so if you want some
change to have a "side-effect", one generally specializes the command to
be a compound command that composes the "normal" command along with any
commands to cause the proper side-effects to happen.


On 23/04/2013 8:40 AM, Ben Cox wrote:
> Hi Ed,
>
> Quote:
>> It's not clear what the various approaching are doing... Adapters
>> normally just respond to changes by updating a view. They should not
>> update the state of the model; that should be done only with commands.
>
> That's good to know!
>
> It sounds more as if you should be specializing the one command to do
> several things which you'd normally do by specializing what the
> "normal" command does in the item generated provider.
> Aha - overriding the createSetCommand methods from ItemProviderAdapter
> to create a compound command instead of the simple SetCommand? It's
> the first time I've seen those methods - sounds like a good idea!


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF Edit - can additional operations happen when a command happens? [message #1047777 is a reply to message #1047401] Tue, 23 April 2013 16:24 Go to previous message
Ben Cox is currently offline Ben CoxFriend
Messages: 17
Registered: June 2012
Junior Member
Thanks, Ed - overriding the create*Command methods in the ItemProviders has done it for me, as you suggested. Now, I have side-effects that are fully integrated into the command stack.

Thanks again.
Previous Topic:[XCORE] Problems with containment proxies
Next Topic:[CDO] DBAdapter.readFields (Out of memory)
Goto Forum:
  


Current Time: Tue Mar 19 05:33:35 GMT 2024

Powered by FUDForum. Page generated in 0.02498 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top