platform-core-home/documents/content_types.html
Parent Directory
| 
Revision Log
Revision 1.11 - (view) (download) (as text)
| 1 : | rchaves | 1.1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| 2 : | <html> | ||
| 3 : | <head> | ||
| 4 : | <title>Central content type catalog for Eclipse</title> | ||
| 5 : | dj | 1.4 | <link rel="stylesheet" href="../default_style.css" type="text/css"> |
| 6 : | rchaves | 1.1 | </head> |
| 7 : | <body text="#000000" bgcolor="#ffffff"> | ||
| 8 : | <h1>A central content type catalog for Eclipse</h1> | ||
| 9 : | rchaves | 1.8 | <p><font size="-1">Last modified: Feb 16, 2005</font></p> |
| 10 : | rchaves | 1.9 | <p><font size="-1"><strong>Note: this document has been updated/extended to depict |
| 11 : | the solution actually implemented in the 3.0 release and changes made during | ||
| 12 : | the 3.1 cycle. The <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/content_types.html?rev=1.4"> | ||
| 13 : | rchaves | 1.10 | original proposal |
| 14 : | </a> written during the 3.0 development cycle, as well as <a href="http://dev.eclipse.org/viewcvs/index.cgi/platform-core-home/documents/content_types.html"> | ||
| 15 : | rchaves | 1.9 | all versions of this document</a> are also available</strong> (<img src="../images/changed.gif" width="12" height="12"> |
| 16 : | marks interesting changes since the original proposal).</font></p> | ||
| 17 : | rchaves | 1.1 | <p><cite><strong>Plan item description:</strong> Content-type-based editor lookup. |
| 18 : | The choice of editor is currently based on file name pattern. This is not very | ||
| 19 : | flexible, and breaks down when fundamentally different types of content are | ||
| 20 : | found in files with undistinguished file names or internal formats. For example, | ||
| 21 : | many different models with specialized editors get stored in XML format files | ||
| 22 : | named *.xml. Eclipse should support a notion of content type for files and resources, | ||
| 23 : | and use these to drive decisions like which editor to use. This feature would | ||
| 24 : | also be used by team providers when doing comparisons based on file type. The | ||
| 25 : | several existing file-type registries in Eclipse should be consolidated. [Platform | ||
| 26 : | Core, Platform UI] [Theme: User experience] (bug <a | ||
| 27 : | href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37668">37668</a>, <a | ||
| 28 : | href="http://dev.eclipse.org/bugs/show_bug.cgi?id=51791">51791</a>, <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=52784">52784</a>) | ||
| 29 : | </cite></p> | ||
| 30 : | <p>This plan item is about two important features: </p> | ||
| 31 : | <ol> | ||
| 32 : | <li>a single content-type repository to be provided by Eclipse on top of which | ||
| 33 : | content-type related features provided by any plugins could be built upon, and</li> | ||
| 34 : | <li>a mechanism for automatically determining the content type given a file name and/or its | ||
| 35 : | contents.</li> | ||
| 36 : | </ol> | ||
| 37 : | <h2>Driving forces</h2> | ||
| 38 : | <ul> | ||
| 39 : | <li>the catalog must be extensible: plug-ins must be able to contribute new | ||
| 40 : | content types;</li> | ||
| 41 : | <li>content types must have an identity, a unique identifier by which they can | ||
| 42 : | be unambiguously retrieved from the catalog;</li> | ||
| 43 : | <li>content types should be hierarchical: new content types are very often specializations | ||
| 44 : | of existing ones (example, Ant Scripts and Plugin manifests are kinds of XML | ||
| 45 : | documents, XML is a kind of text document), so it should be possible for new | ||
| 46 : | content types to inherit interesting properties from existing ones (see <a href="#FAQ-hierarchy">FAQ</a>);</li> | ||
| 47 : | <li>content types have either a predominantly binary or text nature;</li> | ||
| 48 : | <li>content types are associated with specific file names/extensions;</li> | ||
| 49 : | <li>some level of automatic content/name based type discovery must be provided;</li> | ||
| 50 : | <li>existing plug-in-specific content type registry could be replaced/built | ||
| 51 : | upon the central catalog;</li> | ||
| 52 : | <li>encoding determination is strongly related concern and should be taken into | ||
| 53 : | consideration when sketching a solution.</li> | ||
| 54 : | </ul> | ||
| 55 : | <h3>On automatic content type detection</h3> | ||
| 56 : | <p>Content types determine many properties and actions related to files such as | ||
| 57 : | encoding, associated editors, etc. Automatic content type determination allows | ||
| 58 : | content type specific actions without requiring the user to manually define | ||
| 59 : | the content type for a given file. Content type detection is based on:</p> | ||
| 60 : | <ul> | ||
| 61 : | <li>file selection specifications</li> | ||
| 62 : | <li>file contents</li> | ||
| 63 : | </ul> | ||
| 64 : | <p>Content type determination based on file name/extension ("file selection | ||
| 65 : | specs") is the easiest one to compute. Each content type has a set of file | ||
| 66 : | selection specs associated to it. Determining the content type corresponding | ||
| 67 : | to a file selection spec is done by a simple lookup on the catalog. </p> | ||
| 68 : | <p>Content type determination based on file contents is more complex, and requires | ||
| 69 : | examining the contents. Since we are talking about an open set of possible content | ||
| 70 : | types, this examination implies in delegation to content type detectors contributed | ||
| 71 : | by other plug-ins (content describers).</p> | ||
| 72 : | <h2>Solution</h2> | ||
| 73 : | <h3>The proposed API</h3> | ||
| 74 : | <p>The proposed API contains 4 new interfaces in a new package called <code>org.eclipse.core.runtime.content</code>:</p> | ||
| 75 : | <ul> | ||
| 76 : | <li><code><a href="#IContentType">org.eclipse.core.runtime.content.IContentType</a></code></li> | ||
| 77 : | <li><code><a href="#IContentTypeManager">org.eclipse.core.runtime.content.IContentTypeManager</a></code></li> | ||
| 78 : | <li><code><a href="#IContentDescription">org.eclipse.core.runtime.content.IContentDescription</a></code></li> | ||
| 79 : | <li><code><a href="#IContentDescriber">org.eclipse.core.runtime.content.IContentDescriber</a></code></li> | ||
| 80 : | </ul> | ||
| 81 : | <p>Following is a brief description for each of them. </p> | ||
| 82 : | <h4><code><a name="IContentType"></a>org.eclipse.core.runtime.content.IContentType</code></h4> | ||
| 83 : | <p>Represents a content type in the platform. <code>IContentType</code> instances | ||
| 84 : | are provided by the platform, built from extensions to the <code>org.eclipse.core.runtime.contentTypes</code> | ||
| 85 : | extension point. Relevant properties for <code>IContentType</code> are:</p> | ||
| 86 : | <ul> | ||
| 87 : | <li>unique id (example: org.eclipse.core.runtime.xml), which is based on the | ||
| 88 : | plug-in's unique identifier (the registry namespace);</li> | ||
| 89 : | <li>user-friendly name (example: Text, or XML document, or ZIP file, );</li> | ||
| 90 : | <li>file selection spec - comma-separated lists of associated file names and | ||
| 91 : | extensions;</li> | ||
| 92 : | <li>default charset (example: ISO-8859-1, for Java properties files);</li> | ||
| 93 : | <li>content describer (see <code><a href="#IContentDescriber">org.eclipse.core.runtime.content.IContentDescriber</a></code>), | ||
| 94 : | a class that knows how to recognize if a given stream of bytes contains compatible | ||
| 95 : | to the content type, and how to extract other content-type specific information | ||
| 96 : | from the stream.</li> | ||
| 97 : | </ul> | ||
| 98 : | <p>Also, <code>IContentType</code> provides methods that check whether the given | ||
| 99 : | file name is matched by this content type file selection spec, or whether a | ||
| 100 : | content type is a subtype of another content type.</p> | ||
| 101 : | <h4><a name="IContentTypeManager"></a><code>org.eclipse.core.runtime.content.IContentTypeManager</code></h4> | ||
| 102 : | <p>Represents the content type registry. Provides methods for obtaining the content | ||
| 103 : | type associated to a file name, and for discovering the corresponding content | ||
| 104 : | type for a stream of bytes. <code>IContentTypeManager</code> allows clients | ||
| 105 : | to:</p> | ||
| 106 : | <ul> | ||
| 107 : | <li>retrieve the content type for a given id;</li> | ||
| 108 : | <li>retrieve a set of content types associated to a given file name;</li> | ||
| 109 : | <li>discover which content types recognize a given stream as a valid sample | ||
| 110 : | for the corresponding file format;</li> | ||
| 111 : | <li>obtain a description for a stream of bytes, including platform (such as | ||
| 112 : | encoding) and custom (content type specific) properties.</li> | ||
| 113 : | </ul> | ||
| 114 : | <h4><code><a name="IContentDescriber"></a>org.eclipse.core.runtime.content.IContentDescriber</code></h4> | ||
| 115 : | <p>Content-based content type detection and content description rely on specialized | ||
| 116 : | content detectors associated to content types. When a content type is contributed | ||
| 117 : | to the platform, a content describer class may be provided. Content describers | ||
| 118 : | are able to detect if a given stream of bytes is conformant to the content type | ||
| 119 : | file format, and may also be able to extract important properties from the contents, | ||
| 120 : | such as what charset was used to encode the contents (for text files), and any | ||
| 121 : | content type specific information that may be required.</p> | ||
| 122 : | <p>The main method in <code>IContentDescriber</code> is:</p> | ||
| 123 : | rchaves | 1.9 | <p><code>int describe(InputStream contents, IContentDescription description, QualifiedName[] |
| 124 : | options) throws IOException;</code></p> | ||
| 125 : | rchaves | 1.1 | <p>The first thing implementations for this method must do is to check if the |
| 126 : | contents represent a valid sample for their corresponding content type file | ||
| 127 : | format. If not (or if cannot be determined), this method should exit immediately, | ||
| 128 : | returning <code>IContentDescription.INVALID</code> or <code>IContentDescription.INDETERMINATE</code>, | ||
| 129 : | depending on how strict the file format is. Otherwise, this method should return | ||
| 130 : | <code>IContentDescription.VALID</code>, but only after trying to provide all | ||
| 131 : | required information (according to the specified options, if any) by reading | ||
| 132 : | the contents and filling the <a href="#IContentDescription">content description</a> | ||
| 133 : | provided.</p> | ||
| 134 : | <p><strong><em>Note</em></strong><em>: it is essential that for this mechanism | ||
| 135 : | to work in a suitable manner, the execution of content describers by the platform | ||
| 136 : | should not cause the activation of the plugins providing them. In the Eclipse | ||
| 137 : | 3.0 runtime, plug-ins that have built-in bundle manifests will be able to selectively | ||
| 138 : | enable/disable auto-activation on a per-package basis (for more information, | ||
| 139 : | see <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=52393">bug 52393</a>). | ||
| 140 : | Although this will not be enforced by the platform, content describers <strong>must</strong> | ||
| 141 : | be self-contained and not trigger auto-activation.</em></p> | ||
| 142 : | <h4><code><a name="IContentDescription"></a>org.eclipse.core.runtime.content.IContentDescription</code></h4> | ||
| 143 : | <p>Content descriptions are obtained by calling <code>IContentTypeManager#getDescriptionFor</code> | ||
| 144 : | method. A content description contains interesting information (such as encoding) | ||
| 145 : | about an arbitrary stream of bytes. These information are filled partially by | ||
| 146 : | the platform and partially by the content describer elected (if any).</p> | ||
| 147 : | <h3>Conflict resolution</h3> | ||
| 148 : | rchaves | 1.9 | <p>Content types are managed by the platform but plug-ins are in charge of contributing |
| 149 : | content types. While this provides good flexibility, it also opens oportunities | ||
| 150 : | for conflicts. There are a few scenarios where conflicts may arise:</p> | ||
| 151 : | rchaves | 1.1 | <ol> |
| 152 : | <li><em>two content types provided by independently developed plug-ins intended | ||
| 153 : | for the same file selection specification</em> - this may happen for popular | ||
| 154 : | file types that are not provided by the platform. In this case, one of the | ||
| 155 : | rchaves | 1.9 | content types will be ellected arbitrarily. User intervention is required |
| 156 : | (by disabling one of the content types, for instance) if automatic determination | ||
| 157 : | does not choose the preferred content type If multiple content types can be | ||
| 158 : | returned by the API, both will appear in the list.<img src="../images/changed.gif" width="12" height="12"> (see | ||
| 159 : | bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=83004">83004</a>) <font size="-1"> | ||
| 160 : | </font></li> | ||
| 161 : | rchaves | 1.1 | <li><em>two related (but different) content types that share a same file name/extension |
| 162 : | specification</em> - think of general XML documents and Ant build scripts | ||
| 163 : | (a sub-type of XML document, inheriting its file selection specifications). | ||
| 164 : | This is different than the previous case here at most one content type will | ||
| 165 : | be contributing file specs (the more basic type). In this scenario, for APIs | ||
| 166 : | that return content-types based exclusively on file name, the ancestor will | ||
| 167 : | be appear first in the returned array, since it is more general. Note that | ||
| 168 : | when a general type specifies a file extension for it to be associated with, | ||
| 169 : | and a subtype specifies a file name that has the same file extension, the | ||
| 170 : | more specific type will appear before the general one. For APIs that do content-based | ||
| 171 : | analysis, if both content type describers deem the contents as valid, the | ||
| 172 : | more specific content type will also appear first. For two sibling content | ||
| 173 : | rchaves | 1.9 | types that deem a same set of bytes as valid, an arbitrary order will be chosen.</li> |
| 174 : | rchaves | 1.1 | <li><em>two completely unrelated content types that share a same file name/extension |
| 175 : | specification</em> - this is the more unlikely scenario (imagine an image | ||
| 176 : | file format and a word-processor file format sharing the same file extension). | ||
| 177 : | rchaves | 1.9 | In this case, one of the content types will be ellected arbitrarily. User |
| 178 : | intervention is required (by disabling one of the content types, for instance) | ||
| 179 : | if automatic determination does not choose the preferred content type.<img src="../images/changed.gif" width="12" height="12"> (see | ||
| 180 : | bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=83004">83004</a>) <font size="-1"></li> | ||
| 181 : | rchaves | 1.1 | </ol> |
| 182 : | <h3>Frequently Asked Questions</h3> | ||
| 183 : | <ol> | ||
| 184 : | <li> How will plugin providers benefit from a central content type catalog? | ||
| 185 : | <p> Generally by using the same content type registry and sharing the same | ||
| 186 : | rchaves | 1.9 | concept of content/file type. Other examples are: |
| 187 : | rchaves | 1.1 | <ul> |
| 188 : | <li>a builder could use its well-known content type to filter out files | ||
| 189 : | whose names don't match with the content type file section spec;</li> | ||
| 190 : | <li>the user interface could know what editors to offer for a given file | ||
| 191 : | selected (associations between editors and content types should be kept | ||
| 192 : | separately from the content type catalog);</li> | ||
| 193 : | rchaves | 1.9 | </ul></p> |
| 194 : | rchaves | 1.1 | </li> |
| 195 : | <li><a name="FAQ-hierarchy"></a>Why are content types hierarchical? | ||
| 196 : | <p>To allow important properties to be inherited by new specialized content | ||
| 197 : | types: | ||
| 198 : | <ul> | ||
| 199 : | <li>the default charset</li> | ||
| 200 : | <li>text/binary nature</li> | ||
| 201 : | <li>content description</li> | ||
| 202 : | <li>associations defined externally by plug-ins (for instance, any editors | ||
| 203 : | associated with an ancestor should work with any descendants)</li> | ||
| 204 : | </ul></p> | ||
| 205 : | </li> | ||
| 206 : | <li> What happens if the base type for a new content type is not present in | ||
| 207 : | the platform (the plug-in that provides it is not available)? | ||
| 208 : | rchaves | 1.9 | <p>The content type (and consequently any descendants) will be deemed invalid |
| 209 : | and ignored.</p> | ||
| 210 : | rchaves | 1.1 | </li> |
| 211 : | <li><a name="FAQ-MIME"></a>Do Eclipse's content types have anything to do with | ||
| 212 : | IANA's MIME Media Types? | ||
| 213 : | rchaves | 1.9 | <p>Not so far. The main reason is that not every file format with a content |
| 214 : | type in Eclipse will have a MIME type, so we could not use it as the main | ||
| 215 : | association mechanism between content types and applications. We considered | ||
| 216 : | keeping MIME-types as an optional property for each content type, and provide | ||
| 217 : | a method findContentTypesByMIMEType (or something like that), but decided | ||
| 218 : | removing it since there was no sound use case for that (and the idea in | ||
| 219 : | the initial proposal was to keep only the essential stuff to avoid distractions).<font size="-1"><strong><img src="../images/changed.gif" width="12" height="12"></strong></font></p> | ||
| 220 : | rchaves | 1.1 | </li> |
| 221 : | <li>How can users customize the way content types are chosen? | ||
| 222 : | rchaves | 1.11 | <p>By associating additional file specs to existing content types.</p> |
| 223 : | rchaves | 1.1 | </li> |
| 224 : | <li>Can plug-ins override the content type describer for an existing content | ||
| 225 : | type? | ||
| 226 : | <p>Not so far. It is up to the plugin provider to determine whether a content | ||
| 227 : | type describer will be provided.</p> | ||
| 228 : | </li> | ||
| 229 : | <li>Can two completely unrelated content types be associated with the same file | ||
| 230 : | spec? | ||
| 231 : | rchaves | 1.9 | <p>One of the content types (arbitrarily selected) will be chosen as the preferred |
| 232 : | one (the other will also be associated). Priorities are also taken into | ||
| 233 : | account.</p> | ||
| 234 : | rchaves | 1.1 | </li> |
| 235 : | <!--li>How are conflicts (two different content types associated to the same file) | ||
| 236 : | prevented? | ||
| 237 : | <p>They are not. At least, not automatically. It is up to clients to decide | ||
| 238 : | what to do when more than one content type is offered by the platform. A | ||
| 239 : | client that does not care about which one is picked, will randomly choose | ||
| 240 : | one of them. A client that cares but does not know which one to choose may | ||
| 241 : | refuse to use any of them. User-guided code may ask the user what should | ||
| 242 : | be done. The content type chosen may be marked as the default one for the | ||
| 243 : | file spec, or the user may want to mark one as an alias for the other.</p> | ||
| 244 : | </li--> | ||
| 245 : | <li>What if a given file name is matched by two different file specs provided | ||
| 246 : | by two completely unrelated content types? | ||
| 247 : | <p> As seem above, the only way this can happen is when two <em>different</em> | ||
| 248 : | file specs (for instance, a file name and a file extension) accept the same | ||
| 249 : | file name (for instance, one content type is associated with a "xml" | ||
| 250 : | file extension, other is associated with a "plugin.xml" file name. | ||
| 251 : | ) File name specs have priority over file extension specs (so plugin.xml | ||
| 252 : | is a plugin manifest before being a XML document). The normal case is that | ||
| 253 : | the content type that defines a file name spec is based on the file type | ||
| 254 : | that defines a file extension spec (a plugin manifest is a kind of XML document). | ||
| 255 : | This ensures that actions applicable to general XML documents will be applicable | ||
| 256 : | to a plugin manifest.</p> | ||
| 257 : | </li> | ||
| 258 : | rchaves | 1.9 | <li>What are aliases for? <font size="-1"><strong><img src="../images/changed.gif" width="12" height="12"></strong></font> |
| 259 : | (see bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=83004">83004</a>) | ||
| 260 : | rchaves | 1.1 | <p>It is a mechanism to prevent conflicts. When multiple plugins contribute |
| 261 : | content types associated with the same file specs, we have a conflict. Conflicts | ||
| 262 : | rchaves | 1.9 | are bad because introduce ambiguity (what is the right content type?). Most |
| 263 : | of times when such conflicts arise, it is a case of independently developed | ||
| 264 : | rchaves | 1.1 | plugins trying to contribute the same content type (semantically speaking). |
| 265 : | rchaves | 1.9 | Imagine a plug-in com.examples.foo that wants to be associated to the Java |
| 266 : | Source content typ (org.eclipse.jdt.core.javaSource)e, provided by org.eclipse.jdt.core, | ||
| 267 : | but that does not require org.eclipse.jdt.core to be present to work. Such | ||
| 268 : | plug-in can contribute its own Java Source content type (com.examples.foo.java), | ||
| 269 : | and mark it as an alias for the content type provided by JDT/Core. If JDT/Core | ||
| 270 : | is present, the com.examples.foo.java will be omitted from the content type | ||
| 271 : | registry, and all references to it will be automatically interpreted as | ||
| 272 : | references to org.eclipse.jdt.core.javaSource instead.<font size="-1"></font></p> | ||
| 273 : | rchaves | 1.1 | </li> |
| 274 : | <li>How do I prevent my specialized content-type to be disabled even if its | ||
| 275 : | rchaves | 1.9 | parent is not available? <font size="-1"><strong><img src="../images/changed.gif" width="12" height="12"></strong></font> |
| 276 : | (see bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=83004">83004</a>) | ||
| 277 : | rchaves | 1.1 | <p> Sometimes a plugin A does not depend on plugin B, but declares a content |
| 278 : | type which is intended to be a specialization of another content type declared | ||
| 279 : | by B. To prevent the content type declared by A to be disabled: </p> | ||
| 280 : | <ol> | ||
| 281 : | rchaves | 1.9 | <li>declare an alias content type having the intended parent as its target |
| 282 : | (a placeholder);</li> | ||
| 283 : | rchaves | 1.1 | <li>make your specialized content type have this placeholder as its base |
| 284 : | type;</li> | ||
| 285 : | </ol> | ||
| 286 : | <p>If the originally intended base type is available, your base type will | ||
| 287 : | be marked as just an alias, and your specialized content type will be properly | ||
| 288 : | rchaves | 1.9 | attached to the intended content type. Otherwise, the placeholder will be |
| 289 : | enabled, and although things might not be as great as intended (actions | ||
| 290 : | rchaves | 1.1 | associated to the original content type will not be available), your content |
| 291 : | rchaves | 1.9 | type will still be enabled.<font size="-1"></font></p> |
| 292 : | rchaves | 1.1 | </li> |
| 293 : | <li>When should a file-association be contributed instead of declaring a new | ||
| 294 : | (derived) content type? | ||
| 295 : | <p>New content types should be created only if there is no existing content | ||
| 296 : | type with the semantics required. Otherwise, when only additional file specs | ||
| 297 : | must be provided, file associations are the way to go.</p> | ||
| 298 : | </li> | ||
| 299 : | <li>Are file specs inherited? | ||
| 300 : | <p> Only if none is specified in the sub type. </p> | ||
| 301 : | </li> | ||
| 302 : | <li>How does a client figure out whether a given file is a text file or not? | ||
| 303 : | <p>The proposed approach is to check if the file's content type is a kind | ||
| 304 : | rchaves | 1.2 | of the "org.eclipse.core.runtime.text" content type, which is |
| 305 : | intended to be the ancestor for all text oriented content types. If it turns | ||
| 306 : | out to be a very frequent idiom, we might consider proving a convenience | ||
| 307 : | API to do that.</p> | ||
| 308 : | rchaves | 1.1 | </li> |
| 309 : | rchaves | 1.9 | <li>Do content types have to contribute content describers? |
| 310 : | rchaves | 1.1 | <p> No, although if the file has a identifiable signature/format, it is recommended, |
| 311 : | because improves the overall quality of content-based content type lookups.</p> | ||
| 312 : | </li> | ||
| 313 : | </ol> | ||
| 314 : | rchaves | 1.5 | <p> <em>Note: comments are encouraged. Any questions/concerns not addressed here |
| 315 : | should be discussed in the platform-core-dev list, or bug <a | ||
| 316 : | href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37668">37668</a>. </em></p> | ||
| 317 : | rchaves | 1.9 | <h2>Addendum: issues to be addressed in the 3.1 cycle<font size="-1"><strong><img src="../images/changed.gif" width="12" height="12"></strong></font></h2> |
| 318 : | rchaves | 1.5 | <p>The solution described above was implemented and relatively succesful. Some |
| 319 : | components took advantage of the new content type infrastructure, but still | ||
| 320 : | in many cases file-association is being done in an ad-hoc manner. Also, no UI | ||
| 321 : | was provided for customizing content types (such as changing the default encoding, | ||
| 322 : | adding associations with files) so the user has no control on how the content | ||
| 323 : | type detection mechanism works. Thus, the main issues to be addressed in the | ||
| 324 : | 3.1 cycle are:</p> | ||
| 325 : | <ul> | ||
| 326 : | <li>ensure the content type framework works for clients that have not adopted | ||
| 327 : | it yet, or at least we understand why it is not (cannot be made) suitable | ||
| 328 : | to them. Examples are: Platform/UI, Platform/CVS, and products built on top | ||
| 329 : | of Eclipse.</li> | ||
| 330 : | <li>ensure users are granted appropriate means so they can customize the behavior | ||
| 331 : | of content type detection so things just work for them.</li> | ||
| 332 : | <li>ensure content type resolution works (or can be made to work) appropriately | ||
| 333 : | in setups where multiple independently developed products contribute conflicting | ||
| 334 : | content types. </li> | ||
| 335 : | </ul> | ||
| 336 : | <h3>Support more use cases</h3> | ||
| 337 : | rchaves | 1.7 | <p>Ensure the content type support works for the SDK plug-ins and for products |
| 338 : | rchaves | 1.9 | built on top of Eclipse (see bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=78654">78654</a>).</p> |
| 339 : | rchaves | 1.5 | <p><strong>Platform/UI - file/editor association</strong></p> |
| 340 : | rchaves | 1.7 | <p>Content type-editor association is definitely the most important use case for |
| 341 : | the content type support. The basic idea is that for a given file or stream | ||
| 342 : | of data, the UI should be able to:</p> | ||
| 343 : | <ol> | ||
| 344 : | <li>provide a default editor to be used when opening the file</li> | ||
| 345 : | <li>present any other editors that are also able to handle the file</li> | ||
| 346 : | <li>allow the user to pick a completely unrelated file not initially suggested</li> | ||
| 347 : | <li>remember the user decision (if the user wants so) so it becomes the default | ||
| 348 : | for that file</li> | ||
| 349 : | </ol> | ||
| 350 : | <p> <strong>1</strong>, <strong>2</strong> and <strong>4</strong> are currently | ||
| 351 : | supported by the existing file-editor association mechanism. <strong>3</strong> | ||
| 352 : | is being requested by users, and it is orthogonal (as 4 is) to the content type | ||
| 353 : | support provided by runtime.</p> | ||
| 354 : | <p>Content types add a level of indirection between files and editors. At a first | ||
| 355 : | glance, there is no reason why changing the default editor would affect what | ||
| 356 : | content type is assigned to a file, so users should be able to pick up any editors | ||
| 357 : | rchaves | 1.9 | without affecting content type detection.</p> |
| 358 : | rchaves | 1.5 | <p><strong>Platform/Team - binary vs ascii files</strong></p> |
| 359 : | rchaves | 1.7 | <p>The Team plug-in keeps a catalog of file extensions and their expected content |
| 360 : | rchaves | 1.9 | type (either binary or ASCII). If content types were broadly adopted throughout |
| 361 : | the rest of Eclipse (so that most files dealt with by users have a content type), | ||
| 362 : | couldn't the Team plug-in use content type based encoding determination to figure | ||
| 363 : | out a good default for this setting? (see bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=85490">85490</a>)</p> | ||
| 364 : | rchaves | 1.5 | <h3>Give users more power</h3> |
| 365 : | rchaves | 1.7 | <p>Ensure users have means to customize how the content type detection works for |
| 366 : | them. Provide UI for content types. May provide some way of showing related | ||
| 367 : | objects for a given content type (editors, views, comparators, etc). Users cannot | ||
| 368 : | provide content type detection code, so user-defined content types would be | ||
| 369 : | useful only for cases where content type detection is file name based (like | ||
| 370 : | rchaves | 1.8 | for non-formatted text files, such as source files, configuration files, etc).</p> |
| 371 : | <p>A simple plug-in that allows users to add/remove file associations is available | ||
| 372 : | in the <a href="../downloads.html">downloads page</a>.</p> | ||
| 373 : | rchaves | 1.7 | <h3>Improve content type determination</h3> |
| 374 : | rchaves | 1.5 | <p>Ensure content type detection works (or can be made to work) appropriately |
| 375 : | when incompatible products are deployed together.</p> | ||
| 376 : | rchaves | 1.7 | <ol> |
| 377 : | rchaves | 1.9 | <li><strong>project-specific content type resolution</strong> - to reduce chances |
| 378 : | for collisions, there should be a way of constraining which content types | ||
| 379 : | are available on a project basis. One possible solution would be to have content | ||
| 380 : | type-nature associations. Natures could declare some preferred content types, | ||
| 381 : | and those preferred content types would always win (see bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=69640">69640</a>)</li> | ||
| 382 : | rchaves | 1.7 | <li><strong>user-defined content type determination - </strong>two plug-ins |
| 383 : | provide completely unrelated content types A and B for files with extension | ||
| 384 : | ".foo". The current implementation will choose one of them (by priority, | ||
| 385 : | rchaves | 1.9 | depth, or arbitrarily if they have the same priority and depth). If A is automatically |
| 386 : | chosen, the user might want to choose B instead as the default content type. | ||
| 387 : | Instead of doing that on a file basis, it seems better to do it on a coarser | ||
| 388 : | granularity, such as at the project level or at the workspace level (see bug | ||
| 389 : | <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=85765">85765</a>). | ||
| 390 : | </li> | ||
| 391 : | rchaves | 1.7 | <li><strong>product defined policies for overriding content types</strong> - |
| 392 : | a product may want to override some of the existing content type definitions. | ||
| 393 : | Products should be able to do that in a way that would circumvent the regular | ||
| 394 : | conflict resolution.</li> | ||
| 395 : | </ol> | ||
| 396 : | rchaves | 1.9 | <p>See also corresponding PR <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=78654">78654</a> |
| 397 : | - content type should be used universally</p> | ||
| 398 : | rchaves | 1.1 | </body></html> |
| help@eclipse.org | ViewVC Help |
| Powered by ViewVC 1.0.3 |