- 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
- Reserved object prefixes are the following
5 Comments
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:
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:
I'll yield to the experience here. But curious as to how you feel.
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.
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.
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?