Summary: | [content type] need API for related custom objects lookup | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Rafael Chaves <eclipse> | ||||||
Component: | Runtime | Assignee: | Rafael Chaves <eclipse> | ||||||
Status: | RESOLVED WONTFIX | QA Contact: | |||||||
Severity: | enhancement | ||||||||
Priority: | P3 | CC: | andre_weinand, daniel_megert, eclipse | ||||||
Version: | 3.1 | ||||||||
Target Milestone: | --- | ||||||||
Hardware: | PC | ||||||||
OS: | Windows XP | ||||||||
Whiteboard: | |||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 78652, 82986 | ||||||||
Attachments: |
|
Description
Rafael Chaves
2005-02-28 13:34:31 EST
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. [LATER->WONTFIX] The "LATER" bugzilla resolution is being removed so reopening to mark as WONTFIX. |