Community
Participate
Working Groups
I just want to track the following question, I'm not sure it should be changed or not. When you call ContextCore.getStructureBridge() with a content type that isn't supported / available, the context core returns the Resource Bridge by default. This actually went against my expectations which would be to get either a null or failure. Of course, I can check the return instance to see that something went wrong, but it provides a possibility for a later fail that might be difficult to track down.
We won't be able to change that since clients rely on the current behavior. I am wondering though if it makes sense to provide an additional API method that returns null if no structure bridge matches since not all content types map to resources. Shawn, what are your thoughts?
I agree that we could add a new method for this as returning the default bridge may not be what you want. Maybe we could just add a new method ContextCore#getStructureBridge(String contentType, boolean returnDefault) that supports this case and will return null if there are no bridges that match the content type.
(In reply to comment #2) > I agree that we could add a new method for this as returning the default bridge > may not be what you want. Maybe we could just add a new method > ContextCore#getStructureBridge(String contentType, boolean returnDefault) that > supports this case and will return null if there are no bridges that match the > content type. +1 That will have the benefit of clarifying the issue for the current API.
-1 on the proposed signature. Using boolean parameters to switch behavior of a method is not optimal from an API client perspective. Can you come up with another name that's better than getStructureBridgeNoDefault()?
Good point Steffen. I will be hard to come up with a better name, but I will think of it. Maybe something like getContentTypeStructureBridge (or something along these lines that tries to say that it will only return one that matches the content type).
Something like getStructureBridgeByContentType() sounds good to me. I'll put this on the milestone for 3.7 since it should be straight forward to implement. Shawn, feel free to bounce if you don't get around to implementing it.
FWIW, I'm not sure the pattern is that all that bad. It shows up in EMF quite a bit. http://download.eclipse.org/modeling/emf/emf/javadoc/2.5.0/org/eclipse/emf/ecore/resource/ResourceSet.html#getResource(org.eclipse.emf.common.util.URI,%20boolean) OTOH, that's more about *how* something happens then what happens. Hmm.. getStructureBridgeByContentType is a bit confusing because you're already supplying the content type in the normal method. getTypeSpecificStructureBridge, getUniqueStructureBridge, getExactStructureBridge, (or versions with trailing qualifier instead)
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
