Provider of the instance of the given class.
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)
MimeDataProviderinterface 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
Lookupfor a specific
The module itself provides a default implementation of the
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
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
MimePath refers to the 'Editors' folder iteslf.
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
Lookup for the 'text/x-jsp/text/x-java' mime path is made up of
Lookups using the following folders:
Editors/text/x-jsp/text/x-java Editors/text/x-jsp Editors
MimeDataProvider allows registering implementations of
Class2LayerFolder interface in order to supply additional
information about the location of instances registered in the mime type folders.
Class2LayerFolder implementation can specify that instances of
a certain class will be registered in a special subfolder. The
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
that are registered in the
foldManager subfolders. The
hierarchy in this case uses the folders below:
Editors/text/x-jsp/text/x-java/foldManager Editors/text/x-jsp/foldManager Editors/foldManager
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
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'
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)
<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.