Community
Participate
Working Groups
Subject: Editor Registration From: jsussman@us.ibm.com (Jeremy Sussman) Newsgroups: eclipse.tools Organization: http://www.eclipse.org Date: Sep 26 2001 11:50:26 We're working on some plugins for Eclipse, and we've come up with an issue on which we would like some guidance. Basically, the main file that a designer would create for our scenario is an XML file. We are going to create a special editor for this type of XML file -- that is, if you are using our Schema (or DTD), we are going to give you a special editor. We call these files "GIR" files. The problem we are struggling with is how to name these files so that Eclipse will bring up our editor. We seem to have come up with three alternatives: 1. Keep the GIR file as any old *.xml, and register our special GIR editor for all .xml files Advantages: leverage other xml tooling Disadvantages: "pollution" of the editor space for non GIR xml files; our editor won't be the default one - usability issue for regular users of our system. 2. Have a new file extension *.gir and register our editor for that extension Ad: easy usability within Eclipse for normal usage Dis: can't use xml tooling. 3. Have a fixed file name, e.g, gir.xml and register for that; the project name and other details can be derived from internal data inside the file and from the container name (i.e., the Eclipse project), and not be encoded in the file name -- kind of like the generic index.html Ad: can use xml tooling, easy usability within Eclipse Dis: will this hold up in the real world??? I'm wondering what the Eclipse vision is on this sort of thing. Clearly, there are going to be many XML files which should be editted in special ways based on their schema/DTD -- I think this is part of the XML vision. Thanks, Jeremy NOTES: DS (9/26/01 10:26:21 AM) Reply .. Jeremy, You wrote .. > The problem we are struggling with is how to name these files so that > Eclipse will bring up our editor. We seem to have come up with three > alternatives: > 1. Keep the GIR file as any old *.xml, and register our special GIR editor > for all .xml files > Advantages: leverage other xml tooling > Disadvantages: "pollution" of the editor space for non GIR xml files; > our editor won't be the default one - usability issue for regular users of > our system. This is the preferred approach. If taken the external tools work and all of the internal xml editors, including your own, can be used to edit the file. This has the advantage that different users can edit the file in different ways. I know that I prefer to edit xml as text. If you create the file yourself you can set the default editor. Use the following code: WorkbenchPlugin.getDefault().getEditorRegistry().setDefaultEditor(IFile, String) Once the default has been set it will be stored locally. If the user opens the file the default editor will be used. If the file is stored in a repository and loaded by other users they will not get the default. However, as soon as they open it (using Open With) their preferred editor will be registered. I know this is a weak solution. In 2.0 I expect we will consider the idea of a "mime type generator", which can determine the file sub type from the first 128 bytes or so. I have created a feature request. 1GKNZLW: ITPUI:ALL - EC: Need Mime Type Generator Dave
Obviously, one platform-supplied generator won't be able to anticipate all possible content-based distinctions between file types, even those with a given extension. But as long as plugins get to contribute mime-type generators (and generators don't have any arbitrary restrictions, like the first 128 bytes) this solution will work. At least I thought so when I last implemented it. ;-} But it has some drawbacks: 1) Plugins can say what type of files they _can_ edit, even that they wish to be the default editor, but not that they must be the only editor for a given file type. Users must be able to override the editor choice, which in this case means some sort of type-based configuration UI in addition to the current extension-based one. This extra level of indirection isn't as easy for users to understand. 2) Mime types have a few conventions, but except for syntax and a few common examples in RFCs and in use they are just made-up strings. What mime type corresponds to "Java source files containing subclasses of Composite" (an actual requirement)? When plugins make up mime types it is possible to have accidental collisions (same name for different kinds) and disjunctions (different name for same kind). This can be confusing for users. 3) The concepts of kind and encoding are all mixed together in mime types. For example, "text/xml" and "application/xml" are two MIME types describing the same content with different encodings. If you depart from mime types, then you are off inventing your own type signatures. I went down this path once. Believe me, there is no end to the information people will want to encode in these signatures. And it is not hierarchically structured. When all is said and done, it is probably simpler and more flexible to implement the following: a) Allow plugins to declare what they edit by file extension, as they do now. b) Allow users to configure what editors are applied by file extension (or name) as they do now. But extend this so users can configure multiple editors for a given extension (an ordered list). c) Add an interface that allows an editor plugin to inspect its input and return true (yes, it's for me) or false (no, pass it on). This works like pluggable mime type generators, but without the type baggage. To minimize overhead, the interface can be called in a separate plugin class before the IEditor and friends are invoked. Bob bob@objfac.com
I am not sure about an editor rejecting the contents on open time. I would rather see this happen at build time - some kind of interface to do this would be associated with the editor extension point. This would be invoked when the any file of the type was saved ( and built ) and the builder would then accept or reject the file. It could also register itself as the default if it wanted to. This would affect whether the file appeared on the pop-up, and also when the file was opened without specifying a particular editor.
Not all editors have any concept of "build". Do we want to force them to? Since builds occur when a file is saved, do we want each file re-examined on every save? This seems to be unnecessary overhead. I understand a concern about the cost of examining files on every open, but that's not what I meant. Unless the user did something overt to indicate that the nature of the file has changed, like saving the file with a different extension, changing the editor for a specific file or changing the default editor for the file's extension, the file would never be re-examined.
For 2.0 we are considering adding support for product specific overides for editor preferences.
The product override code is in.
