• Layouts: are prefixed according to their use within the solution. Prefixes, of which there can be multiple levels, are delimited by a single colon. Suggested approach is to use the "base table" name as the initial prefix.

    People: Customer List

    good

    People: Customer Search

    good

    People: Customer Detail

    good

    Events: Utility: Copy All Records

    good

Layout objects

  • Layout objects: are prefixed by their corresponding reserved name and use a dot separator. The dot identifies them as layout objects within calculation code. The number of levels used is currently arbitrary based on the solution.
    • Reserved object prefixes are the following
      • field
      • label
      • tab
      • button
      • portal
      • webview
      • chart

        field.customerName

        good

        portal.sideBar

        good

        webview.help

        good

  • No labels

5 Comments

  1. Arnold Kegebein

    Layout objects

    What about object names for multiple identical fields? The object name has to be unique.

    My suggestion: If the circumstances would create duplicate object names, add either:

    • a dot and a further description (e.g. field.customerName.statusbar)
    • a dot and a number (e.g. field.customerName.1)

  2. Josh Ormond

    I'd be interested in some discussion regarding how we are handling this naming convention (the layouts, not the objects...although I think discussion on Arnold's point would be good too).

    While I'm agreeable to starting with the "TableName:", I wonder if it might be beneficial to adopt a similar convention as Table Occurrence Naming and use functional areas instead.  I'd have to play with a few things to see how it reads in use, but everyone's thoughts would be helpful.

    Here is why I ask:

    • A layout for a report based on the People table is functionally different than a data entry form.  The layouts are much different.  Is it easier to find/reference the layout base on the Table you know it's based on?  Or on it's functional use?  People: Customer List or Customer List: People?
    • Layout lists can be organized in more of an Alpha sort.  Creating natural groupings of Layouts.  ( Although, the advent of Layout folders may make this a moot point )

    I'll yield to the experience here.  But curious as to how you feel.

    1. Jeremy Bante

      I've worked on systems with layouts named both ways, and I find table-first naming to be easier to navigate. For example, would I rather be scanning a list of layout names for "Utility: People" or "People: Utility"? There are usually more "Utility" layouts than "People" layouts, so once I find the "Utility" section or folder, I have more scanning left to do than after I find a "People" section. Table-first naming does tend to lead me to having more top-level sections to sift through, but I find that more, smaller sections are easier to navigate than fewer, bigger sections. I think of it sort of like a B-tree structure: the "wider" and more shallow the tree is, the faster it is to search (up to a point). Alphabetical ordering helps, but both helps more.

      1. Josh Ormond

        Makes sense.  I personally haven't used either way long enough yet to say I like one or the other...

        The question came up, because I noticed in some of Matt's videos, that he does it the other way -  Purpose: TableName.

        1. Matt Petrowsky

          To be fully honest. This is one standard which I don't follow fully. I think this one still needs to be fleshed out. Most of the systems I work on don't have hundreds of layouts - so it's easy to keep track of things.

          The needs of a system with hundreds of layouts will require more discipline than one with only a handful.

          The one thing I can say with regards to layouts is that the objective is "quick & immediate" identification. The typical question is likely "What context am I in?" and "What is connected to this layout... um, table occurrence.

          The videos about the KarateApp where I prefix with Utility: LayoutName is a somewhat recent realization that you pretty much have three types of layouts in FileMaker - Interface, Utility and Printed. Unless anyone can list more.

          When it comes to Interface layouts, you know that triggers will potentially exist. A Utility layout are those used for stuff like GTRR's, record loops, virtual lists and other "process operations". And finally, we have Print or Output layouts.

          Are there others I'm missing?