Eliminating model-related dirty state [message #147289] |
Tue, 21 August 2007 11:08  |
Eclipse User |
|
|
|
I'd like to modify the generated diagram editor so that any changes to the
model do not dirty the diagram editor -- instead, those changes are just
committed to the model.
I was thinking of installing a ResourceSetListener on the Editing Domain
for GMF to listen for any changes to the model, and for any change I'd
call doSave on the diagram editor. Alternatively, I could iterate through
the Resources in getResources() that are of the right type and call
save(...) on relevant ones.)
Does anyone see a problem with this approach that I should know about
before I attempt it?
Andrew
|
|
|
|
Re: Eliminating model-related dirty state [message #147373 is a reply to message #147366] |
Tue, 21 August 2007 18:08  |
Eclipse User |
|
|
|
Hi Ed,
On Tue, 21 Aug 2007 17:54:13 -0400, Ed Merks wrote:
> Maybe the option Resource.OPTION_SAVE_ONLY_IF_CHANGED would be useful.
....
That's an interesting option I didn't know about. I don't think it will
solve my issue, though. It will only solve a class of problems where the
changes being committed happen to be the same as those not-yet-committed,
which is actually a small subset in my case.
For more background, I'm trying to make synchronization "sane" across an
EMF Editor, a custom view of an EMF model, and a GMF diagram editor. All
of these editors/views use a single Resource as their backing store, so
that everything stays in sync. Importantly, more than one diagram editor
can be open which references the same model. (This is a stiff
requirement of my application.)
Ideally, they'd all share EditingDomain as well, but currently only the
EMF Editor and the Custom View do, due to problems I've experienced
getting GMF to share it. So a viable (albeit temporary) workaround for
me would have been to just make all user actions write to disk, so that
you could never have a "backgrounded dirty editor" with changes that
conflict with the ones you're about to commit.
Thanks though for the pointer -- this reminds me, I should take a look at
all the options you fine EMF folks have provided on Resources/
ResourceSets! :-)
Andrew
|
|
|
Powered by
FUDForum. Page generated in 0.03714 seconds