D2K modules will become ready to execute, or enabled, whenever their enabling criteria is met. There are two types of enabling conditions: the receipt of data, and the arrival of triggers. Many modules will not need to make changes to their default behavior. By default, modules will enable whenever each of its inputs contains data, and any triggers attached have also arrived. Note: Triggers are not fully supported in the current version.
On the other hand, there are many times when different subsets of all the inputs may be used at different times. For this purpose there is a method that can be overridden to determine when the more complex enabling criterion are satisfied.
public boolean isReady();
This method will return true when the enabling conditions are satisfied. It will return false otherwise.
In order to provide meaningful content for this method, we need to be able to ascertain if there is data available on each of the module's inputs. There is also a method provided for this purpose:
public int[] getFlags();
The getFlags method returns an array of integers. This
array contains a value for each input. For example, the first integer
value represents the number of parcels available in the associated input
pipe. Essentially, we only care that there is one, not how many.
The following is an example of an isReady() method that will return
true when it receives any one of two inputs:
public boolean isReady() {
if(this.getFlags()[0] > 0 || this.getFlags()[1] > 0 )
return true;
else
return false;
}
Triggers on the other hand are controls that are activated whenever a module completes execution. Triggers can be considered messages that are sent to other modules indicating that the module that invoked the trigger has completed. Triggers have changed dramatically in version 3.0 of D2K, and are now very much like pipes that pass strings. The content of the string passed can be used to provide context for the trigger, but it is usually ignored.
By default, a module must receive a message from all of its triggers
before it executes. To override this behavior, the triggersActivated
method can be overridden, and the triggers can be checked manually. There
is an array of Trigger objects in each module called iTriggers
that contains the input triggers for that module. The ready
method of the Trigger object returns true if it has been
invoked. There are other cases where it is useful to have a module
not activate triggers each time it completes an execution cycle. The activateTriggers
method can be overridden for this purpose.
Following is an example of an overridden activateTriggers
method:
protected void activateTriggers() {
// hit all triggers
if (oTriggers != null && this.setTriggers) {
setTriggers = false;
for(int i = 0; i < oTriggers.length; i++)
oTriggers [i].trigger ();
}
}
We can see from the code above that the module containing this method will only activate the
triggers when an internal field named setTriggers is true. This
field is probably set somewhere in the doit method. The triggers
are kept in an array named oTriggers, for output triggers. If the flag
is set, all output triggers are activated. Notice that we first check to see if the
output triggers array exists. If no output triggers are attached, this array
will be null.
![]() |