Community
Participate
Working Groups
Bridges are registered through extension points and their life-cycle is managed by the context framework. Instances should be obtained from the context framework or injected. Creating instances in bridges (e.g. EcoreDiagramUiBridge.getInstance()) can lead to duplicate instances and makes it more difficult to extend and test the implementation.
I spent quite a bit of time trying to discover a way around this issue. This came up somewhere else, I think maybe when discussing packaging. I'd loove to come up with a good solution because as it is now there is a tremendous amount of glue code that is needed in each implementation. I can't say much more until I dive back into this, but IIRC the basic issue has to do with extensibility of the bridges and the fact that both the bridges and the key GMF piece need to be able to coordinate with each other and they're all defined through extensions the life-cycle of which I can't control. Perhaps I can discover the correct UI and structure bridges from an ID. I'll revisit and look into that. See also bug 352897 bug 357134
As discussed elsewhere, to do this correctly is going to take a good deal of engineering work and perhaps implicate some larger issues in context core itself. To understand the scope would itself take a fair amount of time. Steffan, if you are happy with the basic implementation now, understanding that it does have limitations, I'm going to suggest that we a) mark this as an enhancement and b) move it out of the initial release dependency.
Yes, sounds good. We can revisit this in the future and leave the implementation as is. Just be aware that I have seen instances of UI bridges get created twice: through the getInstance() method and the context framework.
(In reply to comment #3) > Yes, sounds good. We can revisit this in the future and leave the implementation > as is. Just be aware that I have seen instances of UI bridges get created twice: > through the getInstance() method and the context framework. Right, it's known that we would have two -- the static instance and the instance that the context creator obtains. I don't see how we can avoid that without a good deal of engineering, which now that I have more experience with the context framework I wouldn't mind doing. :) This shouldn't create any real world problems *as long as the implementation is state-less*. Our implementations are of course, but others following the same pattern may try to add state, which would break. I'll make a note in the DiagramUIBridge class.
