General Modularity Example Module Projects & Files Commands & Scripting Windows Menus Charts Tables Buttons & tools Trees and Taxa Characters & Models Documentation General Utilities Modular architecture Modules: subclasses of MesquiteModule Modules employing other modules Duty Classes Writing modules Documentation for particular modules Packages of Modules Also: User's introduction to modularity class MesquiteModule Example Module

Modules: subclasses of the class MesquiteModule

(updated August 2005)

Modules are subclasses of MesquiteModule, which in turn is a subclass of EmployerEmployee, which in turn is a subclass of MenuOwner. The latter two classes are not intended to be used for anything else other than to serve as superclasses for MesquiteModule. The reason the three classes are separated is to partition the many methods needed into natural groups that are smaller and more manageable. MenuOwner includes all of the many methods to added and manipulate menu items. EmployerEmployee contains the methods to deal with the employee-employer interactions among modules (hiring, firing, and so on). MesquiteModule itself contains methods dealing with other issues. We will speak of all of these methods as if they belonged to the MesquiteModule class.

Note about INSTANTIATION: for MesquiteModules to be used in the system of employees and employers, they should not be instantiated directly. Instantiation is handled automatically by methods of EmployerEmployee when hireEmployee, hireCompatibleEmployee, or replaceEmployee is called. Consequently, subclasses of MesquiteModule do not need and should not have constructors. Instead, the equivalent of a constructor is the startJob method, which is called whenever a module is instantiated for use.

Some of the basic methods of MesquiteModule are the following. The methods underlined are built-in and you won't need to override them. For the other methods to be useful to you, you will need to override them.

• startJob - a bit like a constructor, called when a module is first hired as an employee. Here the module must initialize important variables and so on. endJob() is called when the module is to clean up to be shut down.
• doCommand - called typically when a MesquiteCommand is activated on the module; passes text-based commands to the module (see scripting and commands).
• getSnapshot - called in various circumstances to request a snapshot of current conditions (the text-based commands required to put the module to its current state). Used, for instance, in saving the MESQUITE block of NEXUS files and in cloning windows.
• hireEmployee, replaceEmployee - to hire another module as an employee, with an indication of duties sought.
• employeeParametersChanged - called when one of the module's employees has changed its parameters in a fundamental way and the module should assume recalculations are needed
• addMenuItem and related methods - to request menu items for the module
• getName, getAuthors, getExplanation - called to request basic information about the module.
• getParameters - called when information is needed about the module's current state or calculations. This will be critical for logging and stamping output to document parameters for calculations.
• alert - presents a dialog box to alert the user.
• log, logln - writes text to log window

To be useful, modules must subclass the duty classes which are subclasses of MesquiteModule. Each duty class promises to perform a particular set of functions.

A more complete description of Mesquite's modularity is given under architecture.

To learn how to write a Mesquite module see Making Modules. Also, see the example modules in mesquite.examples.