FileMaker : Avoid "Hard-coding"

Fabrice Nordmann | 8 February 2010

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.