|Re: Grahical editor refresh on underlying resource changed [message #730926 is a reply to message #730920]
||Thu, 29 September 2011 14:46
| Hernan Gonzalez
Registered: October 2010
Location: Buenos Aires, Argentina
Tim Kaiser wrote on Thu, 29 September 2011 11:13|
we check all files in the resource set, since the business objects might
have been stored in a different file.
The diagram needs to be notified if business objects in a seperate resource
in the same resource set
are modified from the outside.
But in that method we are supposedly reacting to a notification for a change in a specific resource. Say I have my diagram with file/uri "x.diag" , and the model in file "x.model", then the resourceset will have two resource with those distinct uris. If I modify from the ouside(say, with the eclipse text editor) the "x.model" file, won't this handleResourceChanged() method will be invoked with the "x.model" resource?
Anyway, I (still) think that, for the particular resource that is reported as method argument, if we can't check the timestamp, the most secure decision is to assume it changed.
|Re: Grahical editor refresh on underlying resource changed [message #731034 is a reply to message #730926]
||Thu, 29 September 2011 18:32
| saurav sarkar
Registered: July 2009
Thanks for your inputs.
So my remaining concenrs are following.
As my resource is changed externally the DomainModelWorkspaceSynchronizerDelegate.handleResourceChanged() becomes imperative i guess.
This method will set the resource changed flag to true and while activation the editor will refresh.
As i mentioned my file system does not respond to the timestamp comparison , is there any other way the resource changed flag could be set
or any other better approaches ?
If not from Graphiti side i look for the Semantic File system implementation and try to do something there.
My Blog http://codifyit.blogspot.com/
Follow me: http://twitter.com/sauravs
[Updated on: Thu, 29 September 2011 18:33]
Report message to a moderator
Powered by FUDForum
. Page generated in 0.03201 seconds