| Interface | Description |
|---|---|
| CollocationQueryImplementation | Deprecated
Use
CollocationQueryImplementation2 instead. |
| CollocationQueryImplementation2 |
A query which should typically be provided by a VCS to give information
about whether some files can be considered part of one logical directory tree.
|
| FileBuiltQueryImplementation |
Test whether a file can be considered to be built (up to date).
|
| SharabilityQueryImplementation | Deprecated
Use
SharabilityQueryImplementation2 instead. |
| SharabilityQueryImplementation2 |
Determine whether files should be shared (for example in a VCS) or are intended
to be unshared.
|
| VersioningQueryImplementation |
Provide Versioning System relevant information about a file.
|
| VisibilityQueryImplementation |
Determine whether files should be hidden in views presented to the user.
|
| VisibilityQueryImplementation2 |
Determine whether files should be hidden in views presented to the user.
|
| Class | Description |
|---|---|
| FileEncodingQueryImplementation |
Information about encoding of a file.
|
| VisibilityQueryChangeEvent |
ChangeEvent subclass to be used by VisibilityQueryImplementation implementations
to fire changes when it's known what files changed visibility.
|
A query is implemented by creating an instance of its implementation interface and registering it to default lookup. Queriers should normally not need to see these interfaces directly since there is a matching utility class which aggregates and prioritizes the results automatically. The utility class in the API can also insulate clients from changes in the SPI.
It is expected that only a small number of implementations of a given query
interface are actually registered at once, so the critical path for answering it
should be relatively short. Where a large number of modules are
able to supply information for a query following a common structure, and it is
possible to quickly determine which one would know the answer, a multiplexing
implementation of the query interface may be registered which can reroute
requests directly to a proper implementation of some secondary interface (again
registered in default lookup). This technique permits the SPI to be very
flexible while keeping a typical API method call fast. For an example, note that
only one instance of
ProjectFactory
is
necessary to support all Ant-based projects: each project type is defined using
an
AntBasedProjectType,
and the
singleton multiplexer delegates appropriately based on the project type ID found
in nbproject/project.xml in the project directory. Therefore adding
a new Ant-based project type should not increase the time required to recognize a
particular Ant-based project on disk.