Package talx.feature

Provides framework for pluggable features.

See:
Description

Interface Summary

DelayedFeature	Interface for features that should be started up after all other features are loaded.
TALFeature	Interface that all pluggable features must implement

Class Summary

AutoLogout	Fires a logout action after some period of inactivity.
AutoSave	Feature to auto save the gui state at regular intervals.
BadTypingCorrection	Beeps and displays a message when the user types onto a button.
CreateErrorMessage	Converts hot key combination to a test action.
InboxClickCorrection	Beeps and displays a message when the user clicks illegally on the inbox.
KeyTest	Converts hot key combination to a test action.

Package talx.feature Description

Provides framework for pluggable features.

The Think-and-Link system is designed to allow extensibility in the form of pluggable features. While features may include visual components, it is a violation of Think-and-link architecture to attempt to modify the behavior of the top-level visual components through a pluggable feature. Instead, you should create either create an implementation class for the top-level component interface (InboxGUI, ReaderGUI, or ComposerGUI) that displays the desired visuals, or create a new set of ActionHandler classes that generate the desired behavior pattern.

Features that change the transport rules are found in the model.filter package.

Features are added to the system by including them in the feature list in the user's settings file. Features are loaded last, so in their constructors, they can ask for:

• Transport Toolkit
• Game Manager
• Mail System Desktop
• Settings
• Receiver Filter
• Sender Filter
• Parameter String

If a feature asks for a receiver filter, it will be supplied with the top of the incoming filter stack (usually, a remote receiver). If a feature asks for a sender filter, it will be supplied with the bottom of the outgoing filter stack. If a feature asks for a String object, it will be supplied with the parameter specified for it in the feature list in the user's settings file. If a feature asks for a ThreadGroup, it will be given the a new ThreadGroup which is a subgroup of the group that contains the controller's action processor.

Features may wish to execute some initialization after all of the filters and features have been loaded. Such features can implement the delayed feature interface. The initialization sequence of delayed features is dependent on the order the features were encountered in the feature list.

To ensure that no feature is in the middle of a transaction when the JVM exits, features that wish to spin off new threads must ensure that those threads are dead before returning from the release method. It is highly recommended that threads be part of the thread group returned from desktop.ActionDispatcher.getCurrentFeatureThreadGroup() and that new threads be given meaningful names to assist in debugging.