FileMaker : Avoid « Hard-coding »

One of the nicest things with FileMaker is how free we are to rename things at any time. No matter if a field is used in a calculation or a script, you can rename it and FileMaker will update all dependencies instantly.

When I try to remember the reasons why I chose FileMaker among the available development tools, I think this one is in the top 5.

It happens though that you need to hard-code things, that is to say quote an item name such as a field name or a value list.

For example, to define an auto-enter calculation depending on active field name, you’ll have to write:

1. Case ( Get ( ActiveFieldName ) = "myFieldName" ; A ; B )

another well known example is

2. ValueListItems ( Get ( fileName ) ; "myValueListName" ) 

This is due to the lack of functions giving information on database structure. One can’t replace expression 1 with

1b. Case ( Get ( ActiveFieldName ) = theNameOfTheFieldThisCalculationIsDefinedFor ; A ; B )[[EDIT: since this article was first written, FileMaker launched FileMaker Pro 10, which makes this example an old story]The GetFieldName function now allows this]

or expression 2 with

ValueListItems ( Get ( fileName ) ; theListOfMyClients )

With generalization of techniques such as plug-ins to trigger scripts (zippScript, DoScript…) that call a script by its name, or LayoutProperties that call layouts by their name… this problem becomes more crucial. Not to mention the PHP API that forces us to hard code everything. This article won’t solve this case, but the equivalent technique could be developed for the php side.

But before that. What is really the problem?

Mainly, referring to a database structure item as a text constant in an expression prevents from renaming this item, unless you investigate the whole DDR (Database Design Report) before renaming anything.

Let’s take a layout called « Customers_list » and a script that goes to this layout using the Go To Layout [ Name by calculation ] option.

Imagine that during the development process this layout becomes a table view. You accurately rename it « Customers_table ». Of course the script is not going to work anymore. (note: in this article, we agree to consider that a script that doesn’t work anymore is not something we want 😉

With time spent on your solution and its increasing complexity, you end up with many items that are not named accurately because you don’t dare renaming them, and you can’t find your way in your naming (not to mention your colleagues or your clients). You might also waste long hours working on a faulty calculation, and finally realize you had just made a typo in the text string. (If you are the one who never ran into this situation, please do not tell me: my only consolation in these cases is to think that probably other guys are as stupid as I am)

At this point, if I did my job correctly and even if you had never felt that there might be an issue with renaming, you should now feel a great anxiety and I’m sure you are wondering what items in your solution you should never rename.

No need to thank me. That was for free.

So here comes the technique we now use to avoid this problem.

It requires a custom function, available on FMfunctions.com

FM_Name_ID ( _Name_ID ; _TLFSV ; _fileName ; _layoutName )

Let’s start with describing this function. We’ll see how and why use it after.

Parameters are:

• _Name_ID: can be given an item name or its ID. For example, let’s send our layout « Customers_list » (for now, we know only its name)
• _TLFSV: the type of item you are working with. It can be:
  • « Table » or « T » : a table occurrence
  • « Layout » or « L » : a layout
  • « Field » or « F » : a field
  • « Script » or « S » : a script
  • « ValueList » or « V » : a value list
• _fileName: the name of the file in which this item is. If this parameter remains empty («  »), it will mean current file (Get ( FileName ))
• _layoutName: this parameter should be filled only if type is Field. Again, an empty parameter means current layout. (Note: as in FileMaker Design functions, this parameter can take a table occurrence name rather that a layout name)

Let’s now see what this function gives for our Customers_list layout:

FM_Name_ID ( "Customers_list" ; "L" ; "" ; "" )

Result is 121. Doesn’t it work at yours? do you get 63? This is normal! The ID of the layout is 121 here on my file, but it can perfectly have a different ID on yours. But it is an ID, which means that unlike the layout name, it will never change. The day you rename it « Customers_table », it will still have the same ID.

So now in my script, instead of using Go To Layout [ name by calculation ], I just have to use Go To Layout [ ID by calculation ], and that’s all!

… well, it would be all if such an option would exist…

Fortunately, the same custom function is going to save us, because it works the other way around too!

I now know the layout ID: 121, what I’ll do is use the old Go To Layout [ name by calculation ], and I’ll define this calculation as:

FM_Name_ID ( 121 ; "L" ; "" ; "" )

And the result is… « Customers_list », of course!

And when I’ll rename the layout, the result will be « Customers_table ». So the script will keep working!

Some will certainly point out that FM_Name_ID ( 121 ; « L » ; «  » ; «  » ) is not really nice to read.

And they are not entirely wrong…

As usual, I would recommend to comment as much as you can:

FM_Name_ID ( 121 ; "L" ; "" ; "" )  // Customers_list

and when you rename the layout, only the comment is not accurate, which is not as critical as the expression result.

Some others would say that all this takes time. Here are some tips to maker it even easier.

• keep in the Data Viewer the expressions that allow you to get current script and current layout IDs)
• store the item IDs so you don’t have to look twice for the same information. So where to store them… well, in the item name, now that you can rename it freely! A script that is called by a plug-in can be called MyScriptName_344 (344 being its ID)

I admit it is not very nice for fields (Name_364 and InvoiceTotal_857 are not nice to work with), so you can use the field comment area.

After some time using this technique for a while, I’m sure you’ll wonder, like me, why you haven’t used it for years.

What the web says

• Check out Matt Petrowsky’s video in FileMaker Magazine
• Subscribe to FileMaker Advisor to get even more info.
• Kevin Frank also published an article on FileMaker Hacks