A modular script is one that performs a useful function with no external dependencies outside that script. This is in contrast to what I ll call a one-shot script, which takes few or no parameters but has dependencies specific to the file that it is being used in.

The ideal modular script takes zero inputs, performs some useful function, and requires no processing of its results. An example of this would be a script that resizes the current window to center the current window on the screen. Because there are no I/O hookups and nothing to be altered outside the script itself, there is no cost to use this script.

More practical examples will require input parameters and output results. However, keep in mind that as the number and complexity of parameter passing increases, the benefit of modularity decreases. There is a tipping point at which the simplicity of one-shot , non-modular scripts that require few or no parameters is the better choice.

Modular Scripting in FileMaker embodies the spirit of object oriented programming. I.e., scripts should be modeled as a collection of interoperable functional objects/modules with a narrow focus. In FileMaker, these modules should favor values passed via parameter in lieu of being derived from the current context. Script modules should return results (e.g., success, fail, canceled, etc) as well as values that might be required in a calling script. Larger routines should rely upon many smaller modules to perform a task, allowing you to pinpoint failures easily, and allowing modules to be reused for many tasks.

Modular Scripting is a way of writing scripts so that each and every script, when copied as is to another solution, will simply work properly when performed at any time.

To "work properly" means to correctly recognize its own context and parameters and either perform the correct action or report the correct error/result code in compliance with the documentation which is included with the script as a leading comment.

Modular Scripting in FileMaker adapts the inheritance property of object-oriented programming to the particular grain of how FileMaker works. Modular Scripting aspires to be as copy-and-pastable as possible by recognizing that FileMaker is not an object-oriented platform, but a context-oriented platform.

Modular Scripts may control themselves by value-based parameters passed to them by the calling context or by identifying the operating context for themselves. Modular Scripts may depend on certain patterned structures in a FileMaker system, but may not depend on any particular schema or context beyond what the script is told via parameters or can infer (such as via Get() and Design functions).

For example, a modular "Print Report" script may need to be told what layout to print, and may even require that the found set be sorted by an OnLayoutLoad or OnModeEnter trigger, but a modular Print Report script would rather not require a specific layout named "Print Report Layout" or a specific "Table::SortThis" field unless these are common to multiple distinct applications of the script in a given solution.

So a single Modular Script can be called to perform the same task as appropriate for many different contexts.