|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
Defines the interface that must be implemented by any configurable component in Sphinx-4. The life cycle of a component is as follows:
register
method is called. This allows the component
to register all configuration parameters. This registration includes the
names and the types of all configuration data expected by the component.
Only properties of these names and types will be allowed by the
configuration system. Note that if a component is derived from another
Configurable
its register method should call super.register
before registering its own properties.
newProperties
method is called. This method is called with a
PropertySheet
containing the properties (from the external
config file). The component should extract the properties from the
property sheet and validate them. Invalid properties should be reported
by throwing a PropertyException
. Typically, once a component
gets its configuration data via the newData
method, the
component will initialize itself. Currently, the newProperties
method is called only once as a result of system configuration during
startup. However, future extensions to the configuration manager may
allow configuration changes while the system is running. Therefore, a
well behaved component should react properly to multiple
newProperties
calls.
Connecting to other components
Components often need to interact with other components in the system.
One of the design goals of Sphinx-4 is that it allows for very flexible
hookup of components in the system. Therefore, it is *not* considered good
S4 style to hardcode which subcomponents a particular subcomponent is
interacting with. Instead, the component should use the configuration
manager to provide the hookup to another component. For example, if a
component needs to interact with a Linguist. Instead of explicitly setting
which linguist is to be used via a constructor or via a
setLinguist
call, the component should instead define a
configuration property for the linguist. This would be done like so:
public static String PROP_LINGUIST = "linguist";
This is registered in the register
method:
public void register(String name, Registry register) {
registry.register(PROP_LINGUIST, PropertyType.COMPONENT);
}
The linguist is made available in the newProperties
method, like so:
This
public void newProperties(PropertySheet propertySheet) {
linguist = (Linguist)
propertySheet.getComponent(PROP_LINGUIST, Linguist.class);
}
getComponent
call will find the proper linguist based
upon the configuration data. Thus, if the configuration for this component
had the 'linguist' defined to be 'dynamicLexTreeLinguist', then the
configuration manager will look up and return a linguist with that name,
creating and configuring it as necessary. Of course, the
dynamicLexTreeLinguist itself may have a number of sub-components that
will be created and configured as a result. If the component doesn't
exist and no configuration information is found in the config file for it,
or if it is of the wrong type, a PropertyException
will
be thrown.
Method Summary | |
java.lang.String |
getName()
Retrieves the name for this configurable component |
void |
newProperties(PropertySheet ps)
This method is called when this configurable component has new data. |
void |
register(java.lang.String name,
Registry registry)
Register my properties. |
Method Detail |
public void register(java.lang.String name, Registry registry) throws PropertyException
name
- the name of the componentregistry
- the registry for this component
PropertyException
public void newProperties(PropertySheet ps) throws PropertyException
ps
- a property sheet holding the new data
PropertyException
- if there is a problem with the properties.public java.lang.String getName()
|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |