|
Re: Eliminating model-related dirty state [message #147366 is a reply to message #147289] |
Tue, 21 August 2007 21:54 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Andrew,
Maybe the option Resource.OPTION_SAVE_ONLY_IF_CHANGED would be useful.
It does what the name implies, i.e., it reads saves into a buffer, reads
the current result, and only if they are different does it overwrite the
resource. Keep in mind though that if the editor isn't dirty then
generally save won't be enabled.
Andrew J. Montalenti wrote:
> 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 22:08 |
Andrew J. Montalenti Messages: 23 Registered: July 2009 |
Junior Member |
|
|
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.03273 seconds