Who should read this document

Purpose of this document

This document was created to serve as a starting point for developers struggling with the development of complex FileMaker applications.

FileMaker Development Methodologies

There are lots of paths to the same destination in FileMaker. In the early stages of a project, choosing one direction over another is often a matter of personal taste and may seem not to matter that much. However, as a solution matures, it becomes clear that some methods stand the test of time better than others. Certain methods maintain flexibility and extensibility, while others become brittle and bloated.

In this whitepaper, I will cover my basic philosophy for dealing with certain high-level aspects of FileMaker development. Although there will be a few specific examples to explain what I mean, the goal is more about considering things in a new light than sharing tips and tricks.

Bear in mind that my suggestions are coming from the perspective of building, supporting, and extending complex multi-user FileMaker applications. These applications are almost always built for external customers, and as such I have little or no control over the scope or direction of the development. I admit that if you are building single-user FileMaker applications for your own personal use, the suggestions offered here may either be overkill, irrelevant, or both.

I should also note that my development methodologies are tightly intertwined with my project management style. If something here seems way off base, please wait to dismiss it as the ravings of a madman until you consider it in the context of how I work with my customers.

Naming Conventions

It does not usually take too much prodding to get a FileMaker developer to wax eloquent about their naming conventions. Everybody has their own way of naming FileMaker objects and frequently will defend their preferences to the death. That being the case, all I want to say about naming is be consistent, and be reasonable.

The advantage of “Being Consistent” is probably self-evident. “Being Reasonable” is admittedly subjective, but I feel I can offer a couple helpful guidelines.

Over-engineering = Hieroglyphics

When you are deciding on a naming convention, just imagine that someone who has never had the pleasure of making your acquaintance may end up working on your solution. For the sake of that developer and the customer they are trying to assist, I urge you to stay away from arcane naming that would require a personal explanation from you.

Another thing to think about is the “readability” of your field names. Read the following field names out loud:

I will wager that you pronounced all of them the same way. And if you didn’t, I will lay a second bet that in short order you would get pretty tired of saying, “zee underscore gee underscore temp underscore text underscore oh one”.

My point is that when talking to another developer about fields, you don’t usually say the REAL name of the field – you leave extraneous stuff out. Even more subtly, I have noticed that when two “homonym” fields exist in a table, it is very tough to confidently remember which one I meant to specify in a particular script step.

The moral of the story is – “keep it simple, stupid”. In general, just name the thing whatever you are going to call it. That is, unless you are working with a customer who calls it something else…

Naming considerations when working with customers

If an end user is going to see something, I usually try to “name things what they are/do” from the perspective of the end user. If your customer uses the term “Billing Sheets” for what you would prefer to call “Invoices”, then name your fields according to their wishes. First of all, it is their system, and second of all, if you don’t do so then you will be forced to create field labels that are very dissimilar to the field names. This can be very confusing later on.

In terms of scripts, if users insist that a button be labeled “TM Callback Report”, odds are I am going to name the script attached to that button “TM Callback Report”. This might seem like a maintenance headache because a user request to change the name of the button would imply that I need to change the name of the script, but in my experience users don’t change the names of buttons that often. And, it is not too onerous to update a script name anyway.

Relationship Graph

If I had to point to the single most dramatic change that has taken place in FileMaker in recent versions, it would be that you have more than one table per file. In fact, you can have close to a million tables per file. Trouble is, relatively early in the lives of most projects, the relationship graph starts to look like there actually are close to a million tables in the file.

This may sound familiar: You make a new file, create a bunch of tables, jump over to the graph and connect all the default table occurrences together. Time passes. You keep adding table occurrences in the graph and before long, end up with what has been dubbed the spider graph - a huge interconnected web of table occurrences. With a spider graph it is very difficult to locate a table occurrence you are looking for and naming them is a nightmare.

The dreaded "Spider Graph"

Figure 1: The dreaded "Spider Graph"

Compounding the issue is that there are a number of places in the FileMaker interface that display the table occurrence names in a list view, rather than in the graphic view of the graph. This makes it extremely hard to select the correct TO because you can’t see how the table occurrences are related - you can only see that they are related or they are not related. So, you have to open up the spider graph and start hunting.

The "Spider Pop-Up Menu"

Figure 2: Pop-ups based on a spider graph are hopelessly confusing. In fact, this is only a fraction of the entire list.

Squids

To avoid the drawbacks of the spider graph, I use a method that I affectionately refer to as "Squids". Squids are similar to what many people refer to as Table Occurrence Groups (TOGs) but with one important difference. Squids are grouped by perspective instead of function. Also, there is a particular naming convention that I associate with squids which seems much simpler than what I have seen with functionally grouped TOGs.

Each squid has a "head" with a bunch of table occurrences "legs" hanging off of it. The squid head is named exactly like the table on which it is based (in fact, the best practice is to use the table’s default TO as the squid head).

Once I have a few squids set up, I like to arrange them all up against the left side of the graph, one after the other. Doing this allows you to pretty much just have to scroll up and down, rather than all over the place. Plus, when you are working on a particular squid, it’s useful to move it up to the top left corner of the graph window. Try it - you’ll like it.

The dreaded "Spider Graph"

Figure 3: A school of squids

The important underlying concept of “squidding” is to set up all the relationships you need from a given table’s perspective. So, if you have 3 tables you will have 3 squids, each with only the relationships that you will need from the perspective of the squid head. There are four rules that you must ALWAYS follow.

The ALWAYS rules

Sometimes you may find it difficult to follow these rules religiously. In cases like this, it is probable that you are trying to solve a problem by "Graphing" rather than "Scripting". That is to say, you are probably doing something in the graph that you should really do with a script. This is a pretty subjective opinion that I will elaborate on in the section on scripting. For now, just follow the rules and I think you will be happy in the long run.

Squid Naming

The naming of squid TOs is important. Each of the TOs in a squid leg is named in a hierarchical fashion similar to a directory path, but I use English language delimiters instead of slashes. The name starts with the squid head name and moves along accumulating TO names. This may seem like no big deal when viewed in the graph, but when viewed in a pop-up menu elsewhere in the FileMaker interface, the usefulness is self-evident. Refer to Figure 4 for an example.

The squid naming convention presumes key-to-key equi-join relationships. When you start getting into wacky relationships for things like portal filtering by date range, it makes sense to name your leg TOs in some way that will make sense to you and your users. Just remember to consider how that name will look when displayed in a pop-up menu.

This is sort of a vague instruction, but if you stick to the “always” rules of squidding, you should be fine. Additionally, in the next section I am going to try to convince you to cut down on adding “single-use” TOs to the graph which will allow you to side-step some of the more snarly naming situations.

The dreaded "Spider Graph"

Figure 4: Squid-style names are self-explanatory in pop-up menus.

Single Use Table Occurrences

One more thing about keeping the graph organized. Try not to add TOs to the graph solely for functions that you could build with scripts. In particular, I am thinking of a developer’s tendency to create TOs solely to execute a “Go To Related Records” script step. The fact of the matter is, you could just as easily do a scripted find. GTRR is great if the necessary TOs already exist for some “unscriptable” reason like displaying a portal, but if they don’t, just script it. With the advent of local and global variables, I find myself doing much more scripting in FM8 than previous versions. Scripts are much more flexible, extensible, and portable if they are not glued to some arrangement of TOs on the graph. Speaking of which...

Scripting

more to come...