Skip navigation links
org.netbeans.modules.editor.mimelookup/1 1.44.1

Package org.netbeans.spi.editor.mimelookup

The SPI allows registering providers of mime type specific Lookups.

See: Description

Package org.netbeans.spi.editor.mimelookup Description

The SPI allows registering providers of mime type specific Lookups. The MimeDataProvider interface can be used to implement such a provider and register it among the services in the default lookup. The editor/mimelookup module will consult all registered MimeDataProviders when creating a Lookup for a specific MimePath.

Default MimeDataProvider

The module itself provides a default implementation of the MimeDataProvider, which creates Lookups from the data registered in a hierachical structure of folders on the system filesystem.

The hierarchy starts with the 'Editors' folder and then contains subfolders for each mime type that has some registered objects. Since each mime type is uniquely identified by its MimePath the string represantation of the MimePath can be used as a filesystem path to the folder holding objects registered for that mime type. For example the 'text/x-java' mime type embedded in the 'text/x-jsp' mime type is represented by the 'text/x-jsp/text/x-java' mime path and the objects/settings specific for this mime type can be registered in the 'Editors/text/x-jsp/text/x-java' folder.

The empty MimePath refers to the 'Editors' folder iteslf.

The Lookup provided for a mime path is in fact a chain of Lookups for all mime paths that can be created from the original mime path by cutting off its mime type components from the end. So, for example the Lookup for the 'text/x-jsp/text/x-java' mime path is made up of three different Lookups using the following folders:

    Editors/text/x-jsp/text/x-java
    Editors/text/x-jsp
    Editors

The default MimeDataProvider allows registering implementations of the Class2LayerFolder interface in order to supply additional information about the location of instances registered in the mime type folders. Each Class2LayerFolder implementation can specify that instances of a certain class will be registered in a special subfolder. The Lookup created by the default MimeDataProvider will then look into the subfolders rather than to the usual mime type folders when looking for instances of that class. An example can be instances of the FoldManager class that are registered in the foldManager subfolders. The Lookups hierarchy in this case uses the folders below:

    Editors/text/x-jsp/text/x-java/foldManager
    Editors/text/x-jsp/foldManager
    Editors/foldManager

Compound MIME types

The default MimeDataProvider supports compound mime types, which are the mime types that have two parts separated by a plus sign ('+'). The compound mime types are heavily used for describing different types of XML files. For example an Ant build script's mime type is text/x-ant+xml, which means that the file is an XML file, but not an ordinary XML file. It's a build script.

From the editor's point of view a file with a compound mime type should offer the behavior of the default mime type (e.g. text/xml) plus special behaviors specific for its original mime type (e.g. text/x-ant+xml). Therefore a Lookup provided for a mime path that contains a compound mime type will collect settings and services from both the folders belonging to the compound mime type and the folders belonging to its default part. The example below shows the list of folders comprising a Lookup for the 'text/x-ant+xml/text/x-java' mime path.

    Editors/text/x-ant+xml/text/x-java
    Editors/text/x-ant+xml
    Editors/text/xml/text/x-java
    Editors/text/xml
    Editors

Ordering and hiding files

When registering instances in the mime path folders it is possible to use position attributes to order the files the same way as you would do it in any other files in a module XML layer. The attributes however will be resolved after all the folders belonging to a mime path are merged. Therefore it is possible to use attributes that define position relatively to a file in a parent (embedding) mime type.

<folder name="Editors">
  <folder name="Popup">
    <file name="org-openide-actions-CutAction.instance"><attr name="position" intvalue="100"/></file>
    <file name="org-openide-actions-CopyAction.instance"><attr name="position" intvalue="200"/></file>
    <file name="org-openide-actions-PasteAction.instance"><attr name="position" intvalue="300"/></file>
  </folder>
  <folder name="text">
    <folder name="x-java">
      <folder name="Popup">
        <file name="org-netbeans-modules-project-ui-RunSingle"><attr name="position" intvalue="400"/></file>
      </folder>
    </folder>
  </folder>
</folder>

It is also possible to influence the default inheritance of files from folders belonging to a parent (embedding) mime type and mask them out by defining a 'hidden file' in the child mime type folder. Hidden files are marked by a special attribute called hidden with a booleanValue equal to 'true'. The example below hides the editor's global CopyAction in documents with the 'text/x-java' mime type.

<folder name="Editors">
  <folder name="Popup">
    <file name="org-openide-actions-CutAction.instance" />
    <file name="org-openide-actions-CopyAction.instance" />
    <file name="org-openide-actions-PasteAction.instance" />
  </folder>
  <folder name="text">
    <folder name="x-java">
      <file name="org-openide-actions-CopyAction.instance" >
        <attr name="hidden" booleanValue="true" />
      </file>
    </folder>
  </folder>
</folder>

Please note that appending '_hidden' to the name of the file does not work, because such a file is made hidden by the XML filesystem implementation when the module layer is loaded and therefore such a file is not visible to the merging mechanism implemented in the mimelookup module.

Skip navigation links
org.netbeans.modules.editor.mimelookup/1 1.44.1