FileMaker Development Conventions - Layouts

Not all FileMaker Developers use the same naming conventions for Layouts!
This document explains our naming convention for Layouts and how we arrived at it.

The goal for naming Layouts (and other code object) include:

  • Technically sound
  • Maximally readable code
  • Performant

Some technical details and background…

  • We use “Anchor-Buoy" to managing the Relationship Graph because it keeps things simple and scales well.
  • A Layout always sits "on top of” the anchor Table Occurrence, which in turn, sits "on top of" a Source Table (which is most often a BaseTable in the same File).

When naming FileMaker Code objects we like to include useful information about the object in the name. In the case of Layouts, useful information includes:

  • Table Occurrence (which tells us “context”)
  • Type of Layout, for example Detail, List, Blank, Print *, etc.

Examples include:

  • Invoice > Detail
  • Invoice > List
  • Invoice > Blank
  • Invoice > Print Statement

Please note that the 3 character used as delimiters [ > ] in the Layout name will need to be escaped when called from an FMP URL, etc. In hindsight, [ - ] or [: ] might (or might not) have been a better choice.

What if you are working on a FileMaker system that has Layout names that you would like to make more readable by renaming? What do you need to look out for when renaming (or deleting) Layouts?

This post...

Renaming FileMaker Objects Without Breaking Code
http://nyfmp.org/2011/09/26/renaming-filemaker-code-objects-without-breaking-code/

…could be useful in thinking about Functions and Script Steps that you have to look out for if you are going to rename Layouts...

Renaming Layouts
Functions
FieldBounds ( fileName ; layoutName ; fieldName )
FieldIDs ( fileName ; layoutName )
FieldNames ( fileName ; layoutName )
FieldRepetitions ( fileName ; layoutName ; fieldName )
FieldStyle ( fileName ; layoutName ; fieldName )
Get ( LayoutName ) “[Layout Name as text string]” // by Calculation
Get ( LayoutNumber ) // if you delete or move layouts
LayoutObjectNames ( fileName ; layoutName )

Script Steps
Go to Layout [by name]

Others?

You will also want to look out for Layouts that are called using external technology, for example via AppleScripts, Data API, CWP, etc.

Feel free to share your thoughts on a best practice naming convention for Layouts.

I do something similar, with some added emoji's b/c I'm a bit dyslexic and it's MUCH easier for me to pick an emoji out of a line of text than the text itself.

I usually use folders too so I usually start with a folder of things that have a standard navigation (so when it changes I only have to change those layouts) and then a separate one for popovers, so my structure looks like this:

Nav (folder)
   Student (folder)
      Student_Detail
      Student_List
      Popovers (folder)
         Student_New
         Student_Edit
   Staff (folder)
      Staff_List
      Staff_Detail

Then I have a folder called:

:cockroach:Debug

The handy emoji makes it VERY easy to visually spot it in the list, and I put a list view of every table in there for when I have to go and debug things. I usually have a folder in debug which is specifically "Imports" just to make it easier to scan.

I also use Emoji's in script names. For example, I sometimes have a script and right after it I have a second script which triggers that script to run on the server (caching, etc.) I used to write "ONSERVER" at the end of every stub script like this, but now I format them like this:

Nightly_Master (this is the script that runs nightly)
-:globe_with_meridians::cockroach: Run_Nightly_Master_ONSERVER (this is the stub script that simply has a "perform script on server script step if I ever have to manually trigger it)

Other Emoji's I use are:

:bar_chart: = Report
:arrows_clockwise: = Refresh/Cache
:arrow_down: = Download/Import
🛜 = Web View

They're not all perfect matches, but they help when scanning through things.

I'm inclined to answer briefly here, even if it doesn't directly fit the thread title:

I use Emojis in Scripts too, but only in comments. They help me to maintain an overview, especially in very complex scripts. For example, I use colored dots to separate longer if statements, e.g.
:large_blue_circle:case 1
:large_blue_circle:end case 1

:purple_circle:case 2
:purple_circle:end case 2

:red_circle: case 3
:red_circle: end case 3

:orange_circle: case 4
:orange_circle: end case 4

or a green checkmark to indicate which result should be available in the current script line, for example

:white_check_mark: Now we have the file path

But I normally don't use them in script names because they do not show in FMPerception.

That's awesome! I also use this one :warning:, which I have quick-keyed so I just have to type three exclamation marks (!) for. I use this for comments that are critical like "don't change the name of this script" or "this part doesn't work yet". or whatever.

Hum,

using emojis in Scripts Name, Layouts' name and comments... this is very clever :clap:.

Images can be used in theme styles. I have styles for off screen objects so that team members can see at a glance that they are not junk, and what type of thing they are