Community
Participate
Working Groups
Model structure bridges should be independent of what kinds of views might be created on the model. Instead they should focus solely on making their meta-model structure accessible to Mylyn. However, currently implementors of bridges have to decide whether GMF editors on their bridge's content type are supported (and extend GmfStructureBridge) or not (and extend EmfStructureBridge). Since Mylyn currently doesn't support multiple StructureBridges with the same or overlapping supported elements, it's also not possible to contribute "plain" model bridges and GMF versions on top at the same time (see e.g. EcoreDomainBridge and EcoreGmfDomainBridge, only the latter of which is registered in its plugin.xml).
I have played around with various variations of doing this and could provide patches for them: 1) optional GMF dependency in o.e.m.mft.emf: Move GMF unwrapping code into EmfStructureBridge with a compile-time dependency and detect at runtime if GMF is available. I don't like poluting the base bridge with (even optional) stuff for downstream bundles 2) extend adapter logic in DomainModelContextStructureBridge.getDomainObject(Object), register adapter in o.e.m.mft.gmf for unwrapping View elements: This solution is pretty generic and should work well for other frameworks besides GMF, too. The adapter logic I have is a bit hacky though, since View does not implement IAdaptable. Additionally, registering new Adapters for 3rd-party types on 3rd-party types might cause side-effects in other code. 3) provide shadow bridges for GMF: change GmfStructureBridge to use delegation instead of inheritance and register it as a shadow bridge for a content-type for which clients need GMF support using the internalBridges extension point. This would allow the most fine-grained control and separation of model and (GMF) view. I would prefer this solution if the internalBridges extension point wouldn't sound so - well - internal...
(In reply to comment #0) > Since Mylyn currently doesn't support multiple StructureBridges with the same > or overlapping supported elements, it's also not possible to contribute "plain" > model bridges and GMF versions on top at the same time (see e.g. > EcoreDomainBridge and EcoreGmfDomainBridge, only the latter of which is > registered in its plugin.xml). Yeah, you've totally grokked the issue I was struggling with! > Since Mylyn currently doesn't support multiple StructureBridges with the same > or overlapping supported elements, it's also not possible to contribute "plain" > model bridges and GMF versions on top at the same time (see e.g. > EcoreDomainBridge and EcoreGmfDomainBridge, only the latter of which is > registered in its plugin.xml). So..one possibility is to ask Mylyn commons to provide this. We've discussed it and I think there might even be an open bug on it. Steffen, any thoughts? (In reply to comment #1) > I have played around with various variations of doing this and could provide > patches for them: > > 1) optional GMF dependency in o.e.m.mft.emf: Move GMF unwrapping code into > EmfStructureBridge with a compile-time dependency and detect at runtime if GMF > is available. I don't like poluting the base bridge with (even optional) stuff > for downstream bundles Right. Big -1 on this option. The base stuff should be as clean as possible. BTW, I'm sure this is a a shared goal, but we also really have to keep in mind the idea that we'd like to provide extensibility for all sorts of view types, including say forms and even non-graphical contexts. > 2) extend adapter logic in > DomainModelContextStructureBridge.getDomainObject(Object), register adapter in > o.e.m.mft.gmf for unwrapping View elements: This solution is pretty generic and > should work well for other frameworks besides GMF, too. The adapter logic I > have is a bit hacky though, since View does not implement IAdaptable. > Additionally, registering new Adapters for 3rd-party types on 3rd-party types > might cause side-effects in other code. Note that code generation might be in play here, so that even a relatively bulky but generic implementation might be ok. > > 3) provide shadow bridges for GMF: change GmfStructureBridge to use delegation > instead of inheritance and register it as a shadow bridge for a content-type > for which clients need GMF support using the internalBridges extension point. > This would allow the most fine-grained control and separation of model and > (GMF) view. I would prefer this solution if the internalBridges extension point > wouldn't sound so - well - internal... I agree 100%. I think the thing is to make it not internal. As a more general discussion, there is some real ugliness in the current code that I really struggled in the limited time available to try to figure out, but ultimately was stymied by the whole issue of the IMHO broken Eclipse extension model -- in that you can't extend extensions. This sharply reduces your ability to provide clean abstractions, and means that you have to resort to a lot of pointless glue code. Without that extension model limitation, code generation wouldn't even be needed -- consumers would simply implement an extension point that wrapped the existing Mylyn extension point and provide the one or two bridges that provide that actual semantics. Nice investigation, Carsten. I'd say proceed as you think best and we'll all take a look at what you come up with.
Any more ideas on this one?
Sorry, my time seems to have been swallowed up by some black hole somewhere the last few months... I have a working solution based on the adapter logic (2) that I could push to Gerrit. However, it still feels a bit "hacky" to me and might cause undesired effects in other code that uses adapters (because it relies on registering a new adapter factory from GMF views to the domain model). I have a much cleaner idea, though: make sure the GMF view model never reaches the StructureBridge by providing a GMF-specific InteractionMonitor. This way the two orthogonal concepts GMF and domain model are completely separated. I think I can have something ready to push to Gerrit by tomorrow.
Look forward to seeing it! The eclipse extension method sucks in that there is really no way to good way to extend and reuse existing extension points. I'm not sure I'm understanding completely though. You still will want to be able to customize the structure and ui bridges separately. How is that supported?
Carsten, we're ready to do a release 0.9.1 (mostly for Papyrus support since that is now working, yeah!). Do you want me to hold for this, or do you think it will be too new at this point?
Well, on one hand, the change is going to be fairly simple as things look right now, so I don't have concerns about stability of the code. On the other hand, it would change the way GMF is adressed to some extent. At the very least, some testing with "old-style" GMF structure bridges would be in order. I'd say go ahead with 0.9.1 and let's look at this for 0.9.2...
Miles, do we aim to include the Papyrus bridge for Juno? Just wondering if we should do the 0.9.1 release for Juno SR1 which is going out in a couple of weeks.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
