Handling business objects shared among different diagrams [message #909558] |
Fri, 07 September 2012 10:29 |
Joao S Messages: 51 Registered: January 2011 |
Member |
|
|
Hello everyone,
Following drill down example in Graphiti Help Contents and as far as i can see, each diagram resorce has its own resource set and shared business objects are synchronized through WorkspaceSynchronizer class which is initialized in the DefaultUpdateBehaviour.
I want to develop a drill down feature but in my scenario, i´m saving my business objects to a legacy database (through an EMF Resource that I wrote) and my diagrams as a binary in that database as well (I achieved this by extending the existing EMF BinaryResource).
So, I´m having some trouble trying to synchronize business objects wich are shared among different open diagrams as WorkspaceSynchronizer doesn´t work for my scenario.
I´ve already tried to extend DefaultUpdateBehaviour so that all diagram resources are grouped in a single Resource Set but doing that TransactionalEditingDomain Command Stack will also be shared among all diagrams which leads to some unwanted behaviour (it gets specially hard to manage UNDO / REDO).
Any thoughts on this?
I´ve already thought about attaching adapters to every emf objets so that i could be notified about changes and then try to synchronize the rest of the resourcesets but i think this would have an horrible performance.
I hope this is clear
Thanks,
Joao
[Updated on: Fri, 07 September 2012 10:32] Report message to a moderator
|
|
|
|
|
|
Re: Handling business objects shared among different diagrams [message #911761 is a reply to message #911166] |
Wed, 12 September 2012 09:17 |
Joao S Messages: 51 Registered: January 2011 |
Member |
|
|
Hello Michael,
Quote:there's a method createEditingDomain() inside DefaultUpdateBehavior that you
can override to create your own editing domain/resource set combination.
Thanks!
I was looking at ResourceSetImpl and i found this:
/**
* Returns a resolved resource available outside of the resource set.
* It is called by {@link #getResource(URI, boolean) getResource(URI, boolean)}
* after it has determined that the URI cannot be resolved
* based on the existing contents of the resource set.
* This implementation looks up the URI in the {#getPackageRegistry() local} package registry.
* Clients may extend this as appropriate.
* @param uri the URI
* @param loadOnDemand whether demand loading is required.
*/
protected Resource delegatedGetResource(URI uri, boolean loadOnDemand)
Following my first post questions, I was thinking about extending ResourceSetImpl and use some kind of global resource registry so that when a shared object, outside of the resource set was need, this shared object resource would be returned here.
I still don´t know if it will work, but i guess i can give it a try.
Thanks,
João
|
|
|
Powered by
FUDForum. Page generated in 0.03128 seconds