Community
Participate
Working Groups
Many clients provide their custom objects that are associated to content types. We should provide API that helps clients to find out whhich of their custom objects are associated to a given content type. This API should perform a traversal of the content type hierarchy, finding matching custom objects (order is important). Also, this API should help clients to deal with legacy associations with file names (as most clients support). Proposed API changes: New sub-interface in IContentTypeManager: // clients should implement interface IRelatedRegistry { // returns objects *directly* related to the given content type. Object[] getRelatedObjects(IContentType type); } New sub-interface in IContentTypeManager: // clients should implement interface ILegacyRegistry extends IRelatedRegistry { // returns objects related to the given file name Object[] getRelatedObjects(String fileName); } New operation in IContentTypeManager: /* Returns all custom objects related to the given content type and fileName (optional, should be provided if available/for legacy support) */ Object[] findRelatedObjects(IContentType type, String fileName, IRelatedRegistry registry) This operation would return an array of related custom objects (as provided by the client implementation of IRelatedRegistry). The order the results would appear would be: 1st - all custom objects *directly* related to the given content type 2nd - all custom objects related to the given file name (if any provided) 3rd - all custom objects *indirectly* related to the given content type
Kim, I believe this API could be very helpful when implementing editor-content type associations lookup.
Created attachment 18538 [details] patch for org.eclipse.core.runtime
Created attachment 18539 [details] patch for org.eclipse.core.tests.runtime
CC'ing Andre.
CC'ing Daniel.
CC'ing Darin. I will release this API as soon this week~s i-build settles down. To give an idea on how it works, here is the corresponding test case. Please let me know if you have any suggestions/concerns about this API. The goal here is to provide an uniform/single way people providing content type related registries look up for the objects they provide (editors, content viewers, object contributions, document setup extensions, etc). public void testRelatedRegistry() { IContentTypeManager manager = Platform.getContentTypeManager(); IContentType text = manager.getContentType(Platform.PI_RUNTIME + ".text"); IContentType xml = manager.getContentType(Platform.PI_RUNTIME + ".xml"); String textEditor = "Text editor"; String xmlEditor = "XML editor"; String legacyTextEditor = "Legacy Text editor"; String legacyXmlEditor = "Legacy XML editor"; final Object[][] contentTypeAssociations = { {text, textEditor}, {xml, xmlEditor}}; final Object[][] legacyAssociations = { {"legacy.txt", legacyTextEditor}, {"legacy.xml", legacyXmlEditor}}; IContentTypeMatcher matcher = manager.getMatcher(new LocalSelectionPolicy()); IRelatedRegistry registry = new IRelatedRegistry() { public Object[] getRelatedObjects(IContentType type) { List result = new ArrayList(); for (int i = 0; i < contentTypeAssociations.length; i++) if (contentTypeAssociations[i][0].equals(type)) result.add(contentTypeAssociations[i][1]); return result.toArray(); } public Object[] getRelatedObjects(String fileName) { List result = new ArrayList(); for (int i = 0; i < contentTypeAssociations.length; i++) if (legacyAssociations[i][0].equals(fileName)) result.add(legacyAssociations[i][1]); return result.toArray(); } }; Object[] editors; editors = matcher.findRelatedObjects(xml, null, registry); assertEquals("1.0", 2, editors.length); assertEquals("1.1", editors[0], xmlEditor); assertEquals("1.1", editors[1], textEditor); editors = matcher.findRelatedObjects(text, null, registry); assertEquals("2.0", 1, editors.length); assertEquals("2.1", editors[0], textEditor); editors = matcher.findRelatedObjects(xml, "legacy.txt", registry); assertEquals("3.0", 3, editors.length); assertEquals("3.1", editors[0], xmlEditor); assertEquals("3.2", editors[1], legacyTextEditor); assertEquals("3.3", editors[2], textEditor); editors = matcher.findRelatedObjects(text, "legacy.xml", registry); assertEquals("4.0", 2, editors.length); assertEquals("4.1", editors[0], textEditor); assertEquals("4.2", editors[1], legacyXmlEditor); editors = matcher.findRelatedObjects(xml, "legacy.xml", registry); assertEquals("5.0", 3, editors.length); assertEquals("5.1", editors[0], xmlEditor); assertEquals("5.2", editors[1], legacyXmlEditor); assertEquals("5.3", editors[2], textEditor); editors = matcher.findRelatedObjects(text, "legacy.txt", registry); assertEquals("6.0", 2, editors.length); assertEquals("6.1", editors[0], textEditor); assertEquals("6.2", editors[1], legacyTextEditor); }
Fixed. Released to HEAD. Patches are obsolete.
Rafael, I see that this could be used in the file buffer's ExtensionsRegistry. Do you see another place in Platform/JDT Text? Since the ExtensionsRegistry already considers the hierarchy and given the load of work we already have we can't change the code to use this new API but would be happily accept a patch.
If you already have code in place that does the right thing, you may leave it as it is, and consider doing it at a later date. This is more intended for new adopters and components thar are not happy/have problems with doing content type matching themselves.
Answering your other question, the only other place in Platform/JDT Text I saw hierarchy traversal being done was DefaultSpellingEngine. But in that case it is ok, because it is looking for one content type, and does not have to support legacy association with file names, the two use cases for adopting the API proposed here.
Talked to Kim about this and decided to revert these changes (once this week's i-build settles down). Might put it back in 3.2 if people need it.
Changes rolled back. Marking as later.
[LATER->WONTFIX] The "LATER" bugzilla resolution is being removed so reopening to mark as WONTFIX.
