Print PDF

FileMaker Inc., with the release of FileMaker 8 and FileMaker 8 Advanced has significantly modified the ways scripts can be written and tested. It is worth it to rethink our approach to scripting from the ground up. Scripting philosophies and techniques might differ user by user, developer by developer, but there are a few common principles worth considering.

FileMaker 8 Advanced introduced several new tools. Copy/paste tables, scripts and script steps, disable/enable script steps, creation of custom menus, use of the data viewer are among the new, FileMaker Advanced-only features. We would encourage everybody developing FileMaker solutions to use FileMaker 8 Advanced. We restrict ourselves to certain basic options accessible from both FileMaker Pro 8 and FileMaker 8 Advanced here.

Basic Principles

1. The script should perform its task(s) and nothing else but its task(s) among all conditions it can be triggered from.
2. The script should be efficient, achieve its objective(s) fast and with using the least amount of resources.
3. The script has to be readable and easy to maintain, regardless of who the developer of the script was.

1. This principle seems obvious. There must be a clearly defined task or tasks for each script. First evaluate the task and decide whether scripting is the best way to perform it. If the answer is yes, start the scripting process with defining the starting point (mapping the context the script is triggered from), the routine(s) you need to perform in order to achieve the intended result. Finally, there should be no unplanned “side-effects” of the script: make sure there are no unwanted changes or unintentional behaviour resulting from running the script(s).
2. Efficiency is hard to measure, easier to spot in a script. It involves speed and resource(s) the script uses. This is why sometimes a script goes through several “iterations” even if the basic functionality is working.
3. Readability and maintenance is the principle that is easiest to forget under pressure of deadlines or in the heat of scripting. Discipline in this respect helps a lot when the developer (the author of the script or the one who needs to re-use or modify it) has to return to the script once the creative rush is over.

Do not forget: common sense is always part of good scripting practices.

Efficiency Considerations

There are several scripting efficiency considerations that are not specific to FileMaker 8 or have been discussed before. We have articles on, for example, script parameters or script variables (see issues 26 through 29). From the still too many options, we will select two.

Go to related record – match all records in current found set

FileMaker, Inc. has performed a face-lift on the well-known and widely used Go To Related Record script step. It is not necessarily bound to the currently selected record any longer. If selected, it can locate and show all records related to all of the records in the current found set. Combined with the excessive options of setting up relationships in the .fp7 format (the format for FileMaker 7 and 8 applications) this script step has the potential to replace several script steps performing complex search operations. Not only does the script get easier to read and work with but the speed gain in performing the script is also considerable. (Speed gain usually shows on large data sets or in cases where the searching of records takes considerable time.)

Get(ScriptResult)

A new, somewhat overlooked but very powerful feature in FileMaker 8 is that the Exit script step can be assigned a parameter. It allows the subroutine to pass a result back to the calling script. Earlier, (that is, before FileMaker a field had to be created and maintained for scripts to communicate with each other. A field, the contents of which was written to disk, was backed up, stored and retrieved – all these processes taking CPU cycles, read/write processes on busy hard drive(s). Fields had to be constantly checked before each use to ensure the content was up-to-date and relevant to the process about to be run. All these for so little gain – many of us just shied away from more efficient scripting structures and use of subroutines in FileMaker too many times. FileMaker 7 introduced the Script Parameter that addressed this problem in many cases – many cases but the one when a subroutine was called and data was to be returned to the originating script. In FileMaker 8, you can wrap up the subroutine with an Exit[resultString] script step and retrieve the resultString with the Get(ScriptResult) function in the main script: the options are as wide as with the Script Parameter to influence the behaviour of the main script.

The Bottom Line

Good scripting is only one of the several aspects of following good development practices in FileMaker projects. Development standards (those of FileMaker Inc. and the more specific ones we use in our projects) are showing the way. File and table structures, the relational model, naming issues, to name just a few, all influence how good our scripting can be. The first step in scripting is to have a scripting practice based on good common sense, providing some sort of scripting consistency. Starting from there, there is always room for improvement.
László Vajda

Other Sites