|
The legacy settings system in the editor module is complicated, error prone and hard to use. It'd been created spontaneously over the years to support immediate needs at that time without paying enough attention to extensibility and interoperability. Historically any module providing editor settings needed to depend on the whole editor module.
The main purpose of this project is to define API for editor settings, that
is lightweight and easily extensible. The API relies on MimeLookup
to provide a way of registering and looking up settings.
The aim is NOT to provide an implementation of a storage for editor settings,
but to define an interface between this storage and clients
like <mime-type> editors, externaleditor, etc.
The editor/settings module consists of several
EditorSettingsAPI
- API
classes for accessing editor related settings. The classes are stored in the
org.netbeans.api.editor.settings package. Each class is responsible
for a different group of settings:
Strings) of colorings and their parameters
(i.e. AttributeSets).
Strings) and their bodies
(i.e. Strings).
MultiKeyBindings.
Each MultiKeyBinding is a list of keyboard shortcuts associated
to an Action.
Editor settings for a particular mime type can be obtained through MimeLookup
MimePath mimePath = MimePath.parse("text/x-java");
FontColorSettings fcs = (FontColorSettings) MimeLookup.getLookup(mimePath).lookup(FontColorSettings.class);
Question (arch-usecases):
Describe the main
use cases of the new API. Who will use it under
what circumstances? What kind of code would typically need to be written
to use the module?
Answer:
All editor settings are mime type specific and therefore should be retrieved
using MimeLookup. The following example shows how to retrieve
the FontColorSettings for java files and how to get AttributeSet
with coloring attributes for a particular coloring (i.e. in this case the
colors used for highlighting selected text)
MimePath mimePath = MimePath.parse("text/x-java");
FontColorSettings fcs = (FontColorSettings) MimeLookup.getLookup(mimePath).lookup(FontColorSettings.class);
AttributeSet coloring = fcs.getFontColors(FontColorNames.SELECTION_COLORING);
If clients need to react on changes in editor settings they can attach LookupListener
to the LookupResult they got for their particular settings class
from MimeLookup. The following example shows how to do it.
MimePath mimePath = MimePath.parse("text/x-java");
Lookup lookup = MimeLookup.getLookup(mimePath);
LookupResult result = lookup.lookup(new Lookup.Template(FontColorSettings.class));
result.addLookupListener(new LookupListener() {
public void resultChanged(LookupEvent ev) {
//... the client's response to the settings change
}
});
The FontColorSettings class implementor is responsible and will create
a new instance of FontColorSettings whenever some coloring will change.
This new instance will be placed in MimeLookup replacing the old one.
The sources for the module are in the Apache Git repositories or in the GitHub repositories.
These modules are required in project.xml:
java.io.File directly?
Answer:
No.
Question (resources-layer):
Does your module provide own layer? Does it create any files or
folders in it? What it is trying to communicate by that and with which
components?
Answer:
No.
Question (resources-read):
Does your module read any resources from layers? For what purpose?
Answer:
No.
Question (resources-mask):
Does your module mask/hide/override any resources provided by other modules in
their layers?
Answer:
No.
Question (resources-preferences):
Does your module uses preferences via Preferences API? Does your module use NbPreferences or
or regular JDK Preferences ? Does it read, write or both ?
Does it share preferences with other modules ? If so, then why ?
Answer:
No.
org.openide.util.Lookup
or any similar technology to find any components to communicate with? Which ones?
Answer:
No. It only defines the classes that can be looked up via MimeLookup.
Question (lookup-register):
Do you register anything into lookup for other code to find?
Answer:
No.
Question (lookup-remove):
Do you remove entries of other modules from lookup?
Answer:
No.
System.getProperty) property?
On a similar note, is there something interesting that you
pass to java.util.logging.Logger? Or do you observe
what others log?
Answer:
No.
Question (exec-component):
Is execution of your code influenced by any (string) property
of any of your components?
Answer:
No.
Question (exec-ant-tasks):
Do you define or register any ant tasks that other can use?
Answer:
No.
Question (exec-classloader):
Does your code create its own class loader(s)?
Answer:
No.
Question (exec-reflection):
Does your code use Java Reflection to execute other code?
Answer:
No.
Question (exec-privateaccess):
Are you aware of any other parts of the system calling some of
your methods by reflection?
Answer:
No.
Question (exec-process):
Do you execute an external process from your module? How do you ensure
that the result is the same on different platforms? Do you parse output?
Do you depend on result code?
Answer:
No.
Question (exec-introspection):
Does your module use any kind of runtime type information (instanceof,
work with java.lang.Class, etc.)?
Answer:
No.
Question (exec-threading):
What threading models, if any, does your module adhere to? How the
project behaves with respect to threading?
Answer:
No special threading models used.
Question (security-policy):
Does your functionality require modifications to the standard policy file?
Answer:
No.
Question (security-grant):
Does your code grant additional rights to some other code?
Answer:
No.
java.awt.datatransfer.Transferable?
Answer:
No clipboard support.