Database Reference
In-Depth Information
Creating Modular Scripts
In the last section, you saw a script that shows a message in a merge variable if no money is
owed on an Invoice. But the script steps that show the message aren't in the Custom Layout
Dialog Box script. Instead that script calls the “Show message in a merge variable” script,
using the
Perform Script
step. When you
Perform
one script from within another, the
script you perform is called a
subscript
.
Figure 17-9. Putting a message in a merge variable lets your users work more efficiently, since
they don't have to click OK to close a dialog box. But this method isn't suitable for scripts that
need to take action based on your users feedback.
Subscripting is the essence of
modular scripting
. You write a simple script that does one
thing really well and then you call that script anytime you need that action performed. This
process saves you work in two ways. First, if you ever have to change the way you show
messages in a merge field, you can change it once, and everywhere the script is called it will
run with the edited behavior. Second, it can make your work faster and less prone to error be-
cause it's far easier to test a short script than a long, hairy one.
But modular scripts need to be able to run in multiple contexts. The “Show message in a
merge variable” script has no context at all. The only thing it needs to work in any context
you perform it in is a merge variable named
<<$$message>>
on the layout that's active when
the script runs. In this section, you'll learn more about the
Perform Script
step and how all
these scripts relate to one another as they run. In later sections, you'll learn more about mak-
ing scripts dynamic—they can run on both an Invoice and a Customer layout, for ex-
ample—by providing script parameters.
