Community
Participate
Working Groups
I cam across this working on a plugin of the CompilationUnitEditor that requires a specialized IDocument, so I need my own DocumentFactory to claim .java files. It looked like this extension point might be the thing to use. Unfortunately, when two plugins claim the same filename extension for this point, the behavior isn't defined and seems to be up to the order in which the plugins are loaded. What I'd really like a way to configure which DocumentFactory is used on something like a per-editor or "per-plugin" (whatever that would mean) basis. At the very least though, the behavior should be specified.
It might be worth pointing out that the reason I want to use this extension point is that I want my own IDocument implementation to be used for the Java source files loaded by my editor (which is a subclass of CompilationUnitEditor). I haven't found any other reasonable way to get my document class to be used by the editor.
You are right with that it is not specified what happend when there are multiple contributions for documentCreation refering to the same file extension. We will add a specification. In your case, you can use a custom document provider. Document providers are shared between editors of the same type but not between other editors or arbitray clients. This is what file buffers are for. Thus, making documentCreation editor or plug-in specific contradicts the idea of file buffers.
Thanks. I'll move this discussion to the newsgroups shortly, but since others running into this problem might be trying to do the same thing as I, I'll ask one more question here: I actually started out doing this before realizing that the Document object was being created by the plugin using the extension point above. If I'm subclassing a CompilationUnitEditor and CompliationUnitDocumentProvider, which methods should I override to have my own Document be backing the Editor (and have all the JDT stuff still work)? getDocument() doesn't quite do it because other methods in TextFileDocumentProvider don't go through that interface to access the document (rather, they go through the FileInfo.fTextFileBuffer field directly), createFileInfo() doesn't quite do it because both CompilationUnitDocumentProvider and TextFileDocumentProvider do lots of special work on the FileInfo object and also populate the FileInfo.fTextFileBuffer field, so there doesn't seem to be a reasonable place to swap out the file buffer (or its document) for my own. I guess this is the consequence of trying to hack internal classes... ;-)
The file buffers plug-in now supports content types (see IContentType). *** This bug has been marked as a duplicate of 49594 ***
