Lookups.See: Description
| Interface | Description |
|---|---|
| Class2LayerFolder<T> | Deprecated
Use
MimeLocation instead |
| InstanceProvider<T> |
Provider of the instance of the given class.
|
| MimeDataProvider |
Provides a
Lookup for the specific MimePath. |
| MimeLookupInitializer | Deprecated
Use
MimeDataProvider instead. |
| Annotation Type | Description |
|---|---|
| MimeLocation |
Should be used for services that are to be registered to the MimeLookup and that
need a specific subfolder to be used for the registration (optional, mime-type root
will be searched if this annotation is missing)
|
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.
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
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
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.