The latest version of FMPerception (16.1.1) includes a new report: Indirection Sources for FileMaker. What is FileMaker indirection, you ask? Let me illustrate with an example.
I’m standing, somewhere near a corner, at the Welcome reception for DevCon 2018, with some beverage in my hand. Someone comes up and talks to me and asks who the FileMaker community Award winner was last year. I say “Josh”. “Who?” they ask. “Josh,” I say. “Which Josh?” I point to the middle of the room. “That one.” “There’s lots of them,” she says. Finally, in desperation to go back to my silent-corner standing, I walk to the middle of the room and drag the correct Josh over to where the woman awaits. “This Josh” I say.
That, friends, is Indirection.
Indirection, in software development, is tightly defined as referencing something by name rather than the value itself. In FileMaker, we often use indirection. We reference the name of something rather than the thing itself. It sounds like a big no-no, but that’s far from the truth. Indirection is useful and valid, but it does require some “knowing what I’m getting into” thought. You have to be aware of its use in your custom app.
FileMaker Indirection, Described
In my story above, I first used the person’s name to whom I was referring. I said the word “Josh”. I could have even spelled it for her: “J-O-S-H”. In FileMaker, we can use the script step Set Field By Name [] and literally type in the field name: Set Field By Name [“Students::FirstName”]. Both of these are indirection because they refer to the name of the object (person or field).
Examples of FileMaker Indirection
As we said before, FileMaker indirection is fine. Indirection allows us to be clever in our coding (see the links below for ideas). However, it will cause problems when a field name or layout name or table occurrence name is changed by a developer other than the original one (or by the original developer who forgot they used indirection in a script step).
Other Thoughts on FileMaker Indirection
There have been many discussions about indirection in the past:
- DBServices wrote a few posts on indirection, examining what it is and how to code around it.
- Wim Decorte at Soliant Consulting has talked about it in reference to ExecuteSQL (a common indirection source)
- Mike Mitchell spoke of indirection at FileMaker DevCon 2017. Read his notes and watch the video.
- And we have discussed it in terms of the function GetFieldName().
Each one of these also give some good ideas on how to use indirection effectively. But keep on reading here.
Find Your Uses of FileMaker Indirection
So FileMaker indirection is a thing, and a thing we therefore should consider. And with FMPerception 16.1.1, we can examine all of our uses of indirection in a new report which points out all the script steps, functions, and field calculations in which we used something that could cause indirection.
A list of FileMaker Indirection functions, script steps, and field calculations
If [ Get ( LayoutName ) = “Students”] //Do some code here End If
How this is Helpful
I took a system upon which I’m currently working, created an XML DDR, and opened the DDR up in FMPerception so that I could examine my file as it is mid-development. As I examined the Indirection Sources report, I stopped and considered three things.
First, I got to consider how each function or script step is used and where it is used. I can see in my 20 uses of ExecuteSQL that sometimes I hard-code the field name, and sometimes I use a proper custom function to reference the field. I should really go and fix those hard-coded statements.
I’m using ExecuteSQL () 20 times in my custom app.
Second, I can consider the sheer number of indirection uses for a decision on how much to change schema names. If I’m using Get ( LayoutName ) = “Students” 100 times, I probably do not want to change the name of the layout referenced here. If I do want to remove this indirection source, I can use methods described in the links above. This consideration may be useful in determining how much work it will be to maintain and add to a newly-acquired system.
Third, the report made me consider indirection as I continued to develop. Every time I used ExecuteSQL () I made sure to use custom functions to get the reference of each field and table in the statement.
FMPerception provides another clear view into your custom app through the Indirection Sources report. It will be useful for many developers who are taking over a system and for monthly maintenance. We think it will be a valuable tool for anyone looking to tighten up their system and make it better. If you’ve not yet tried it out, head over to the FMPerception page to read more about it and give it a try.
Trackbacks/Pingbacks