FileMaker Inc. 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.
- The script should perform its task(s) and nothing else but its task(s) among all conditions it can be triggered from.
- The script should be efficient, achieve its objective(s) fast and with using the least amount of resources.
- The script has to be readable and easy to maintain, regardless of who the developer of the script was.
- 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).
- 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.
- 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.
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. 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.)
A somewhat overlooked, but very powerful feature 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, 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. 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.
If you enjoy our FileMaker blogs, be sure to subscribe to our Core FileMaker Newsletter!
And as always, Thanks for Reading!