Overview
As a developer of any complex FileMaker solution, the need to retain a clear picture of how the solution is structured becomes increasingly critical as the size of the solution increases. In attempt to reduce potential confusion and to increase solution comprehension, a developer perspective of the data is often VERY helpful. In order to achieve this, you should use Developer layouts.
A Developer layout is simply a dedicated layout which is used internally within your solution and never shown to end users. It serves as a canonical location for scripting and a visual reference for the underlying data in your solution.
Guidelines
Following the standards outlined in Table occurrence naming for developer tables. This best practice suggests you create a correspondingly named layout with the following features. Keep the names the same because a unified structure is easier to follow.
- Always hide the layout within the Manage Layouts dialog by unchecking it. (Don't allow it to be viewed)
- Use the color Green in the header to indicate the table resides within the current file.
- Use the color Red in the header to indicate the table resides in an external file (data separation model)
- Identify external tables within the header by adding the file name (including .fp7)
- Use a sub-section below the header in order to fully document the purpose, function and any special details about the table (since you can't do this within Manage Database). This area can be as large as needed.
- Limit the view method to Table and turn on the headers and footers (image 3 & 4)
- Use a mono spaced font such as Courier, Monoco or (my favorite) DejaVu Sans Mono for all fields (this helps with zero (0) versus "O" type issues)
- Specify the body part to use an alternating color for easier row identification (double-click on body part to set)
- Assign the OnLayoutEnter trigger for each Developer layout to a script which enforces table view and sets the window title (image 6 & 7)
Summary fields
In attempt to keep your Developer layouts as quick as possible, it's suggested you do not include summary fields (because of long calculation times required) within the list of fields shown. You can either use the footer area or the sub-section within the header to indicate their existence.
Deprecated fields
You can also use the sub-section or other layout parts to indicate fields which are identified as deprecated or scheduled for future deletion.
Opening multiple developer windows
When working with the Mange Layouts dialog, you can select multiple developer layouts and click the Open button in order to open all selected.
Image #1 (local-to-file developer layout)
Image #2 (external table developer layout)
Image #3 (limit to Table view)
Image #4 (turn on show header and footer)
Image #5 (set body part to alternate colors)
Image #6 (set OnLayoutEnter trigger to same named script)
Image #7 (use an OnLayoutEnter Developer script to enforce table view and set title)
14 Comments
Perren Smith
Me likey!
One small personal preference: I omit summary fields from developer layouts that I build to keep them from annoying the heck out of me if I'm in a huge found set.
I make a note on the layout (footer I guess in this instance?) that they do exist and provide their names as a quick visual reminder for others who may use this layout for reference purposes...
Oh, and for those of us in situations where we have scheduled a field for depreciation, yet cannot rename them due to external conditions beyond our control, maybe noting that in the header above the field is handy too.
--Perren
Matt Petrowsky
Nice suggestions! I like the idea about deprecated fields.
I'll add the information about not including summary fields as a tip.
As soon as we get some more feedback, we can move it into Best Practices.
Anonymous
I put summary fields in the header of developer layouts. I "see" summary fields as part of my information about the table
Josh Ormond
The biggest problem with Summary Fields on these developer layouts is the performance hit ( on large found sets ). I can see using them on occasion, but for me it's just too frustrating to sit there and wait for the "Summarizing..." dialog. Since I'm mainly using the developer layouts for scripting and testing during devleopment, or just when I need a clean layout to do data manipulation ( user never sees )...having summary fields has limited usefulness.
I will put them on other layouts, and refer to them when scripting / testing...but I rarely need to know totals and aggregate figures when I'm designing interface or process flow.
Jeremy Bante
I can tolerate using color as an indicator of local vs. external status. The file name (a much more self-explanatory signal) is there for external tables; can we have a similar verbal (local) flag for tables within the file? (A general design rule I use is "It has to be navigable when you reduce it to black and white — not grayscale, 1-bit BLACK and WHITE.") Color does stand out more than a file name, so I'm fine with that. However, red and green is the last pair of colors I would use. Red-green colorblindness is surprisingly common. Blue and yellow would be more consistently perceived.
Matt Petrowsky
Wow, "tolerate" that's an interesting word. This is a proposal... (be nice now)
Here's my argument for not using a "local" flag. The lack of something is just as much an indicator as having something - at least when you do have something. In fact, having to actually decipher "local" in relation to "SomeFileName.fp7" is something that has to be done in the brain.
Whereas, I would assume that seeing the "dash file name" ( - SomeFileName.fp7 ) is the giveaway - despite the color. Plus the .fp7 is the obvious part.
Regarding the color: I would hope that a color blind developer would adjust the colors used. Not that we're trying to exclude those who are, but rather for those who aren't - Green means "Go" (otherwise, positive or "local") vs. Red means "Stop" (or negative, not actually bad in this case, or "external")
Jeremy Bante
I was just being a pretentious designer.
The lack of something is only an indicator if you know there can be something there — it requires familiarity with the convention. I'd rather use conventions that are helpful even to those not familiar with the convention, one of the same reasons not to use abbreviations or codes when naming things. However, your argument for the particular color choice changed my thinking about the "local" flag, anyway. The better argument for not using a "local" flag is so that information is only presented as needed. A local table has less to be concerned about than an external table, so it's more efficient to just not say anything.
Yellow is traditionally used for caution, which is more fitting for an external table; but that connotation probably isn't as strong in the background for a header area. The "Go" and "Stop" metaphor hadn't occurred to me, and I still don't feel that effect looking at the screenshots. Using color to communicate meaning is a dangerous game, so it's good that it's redundant with the file labeling. Now that I say that, something that might guide unfamiliar developers to the interpretation of the colors more quickly might be to restrict the use of Red to the name of the external file, which should be in the largest typeface on the layout (same size as the table).
Anonymous
This one sounds like it is ready for the Best Practices section.
I agree with Jeremy that using colors to indicate meaning should be used with caution. However, some things are natural. When people see red numbers...they know it can represent a negative number. That is, of course, context sensitive. Red numbers on a basketball scoreboard aren't viewed the same as red numbers with a $ in front.
For me, that Red background reminds me that I am working on the interface file, and green says you are working in the data file. It is a visual cue that I can process without taking my thoughts off of what I am doing. Although, I could develop the same response if I used White/Black backgrounds instead. Either way, this practice is a good one to get into.
Josh Ormond
Matt Petrowsky
I agree, I've been using this one for a while now and it's just super easy and helpful. Plus, you just select any Developer layout and click duplicate for your next one- easy. I'll move it from proposals to Best Practices
Anonymous
I am surprised that you use table layouts. No matter how careful I am, I end up adding a field or a record sometimes. I have full access of course. It may seem like a small thing because I usually notice it but not always. Also, even if I notice it and delete the accidental record, it has caused an increment of serial. Since our records never should be deleted, this increment would be concerning.
I use form view. And I put summary fields on second of a two-tab panel. I like the color ideas and I like this website. Thank you for providing it for our use. It helps a lot.
Daniel Smith
This doesn't work on FileMaker 12 - maybe it will again in future versions, though?
I think there are some fairly major reasons that these tables are NOT ideal for scripting:
With all this talk of differentiating local vs. related tables, it sounds to me like you are including this set of layouts in all interface files? Even in a solution with multiple interface files? If these layouts are not going to be used for scripting, then I think only local tables should have a "Developer" layout. One of my reasons for thinking this way is that notes about a tables purpose/summary fields should only exist in one place
I think the concept of "Developer layouts" is sound, but the recommended implementation method should be refined.
Matt Petrowsky
There's no implication that a Developer table is the singular 'ideal' for functional situations. It's just there if you need it and don't want to create a dedicated layout - think of an abstracted record creation routine for a table (non-looping). If relationships are needed for a given solution then I would suggest a Utility layout. A dedicated layout which serves the purpose of the intended utility. Where additional relationships will obviously be used.
The inherent functionality of Developer tables is not to provide solution specific functionality. They are proposed to promote uniformity across solutions. Something you can expect to be there if a solution says it conforms to these standards. Where viewing non-visible data is possible.
While I use Developer tables myself for data reference, I often create dedicated layouts, stored within a folder aptly named "Utility" within the Manage Layouts dialog where those layouts are set to Form View when record looping is required.
Additionally, the results of the OnLayoutEnter trigger can be avoided by following Suppressible Triggered Scripts.
I'll have to review the proposed usage as 12 has revised it a bit. I currently only include Developer layouts within my UI files and my data files only get them when necessary. As far as I use them, they are canonical in terms of documentation. If there are multiple UI files, then the developer(s) need to decide which file should be the authoritative one.
Very much like git repositories, you can have clones all over the world, but there is one of them that is considered authoritative.
Comments?
Daniel Smith
That makes sense. It was either the way it was written, or the way I interpreted it that gave me the impression that this is a suggested layout to use for scripting. If nobody else got this impression, then I guess it's just me and it's fine as written.
I still don't agree with documenting a data file in one of (possibly) multiple UI files. Imagine a situation where you took over another developers database with 5 different UI files - how would you know where to look for these notes? Then, imagine that those same notes were in the data file - you would "stumble" across them almost immediately. So, I suggest this method be modified to recommend developer layouts be added to the data file as well, and have that be the only place for notes about that table.
I think having a central place to store notes about tables is a great idea - I often find myself looking for a "Comment" section for tables, like we have for fields, and using a layout as mentioned provides a place for those comments.
I agree with including these Developer layouts in UI files for any tables that the UI file references, since each UI file might not reference all tables from the data file.
I also agree with having a script trigger on these layouts that enforces table view (since opening a layout from the manage layouts window causes that layout to take on the view mode from the current window)... and I just realized a reason for modifying the window title: so the list of windows in the "Window" menu item matches the table name that the window will be displaying records from.
Josh Ormond
I think the confusion may come in with the word "canonical". Here it's reference is to a set of tables and layouts that adhere to a general rule or accepted procedure. As opposed to being "ideal" for something. Of course, that general rule being that it is in all your files. At times, it is definitely import to be able to get a clean view of exactly what is happening with the data, without all the Scripts, Triggers, and fireworks going on in your UX layouts. If you always do it the same, you always know where to look. Same for anyone even somewhat familiar with the standards here...because we are all doing it basically the same.
I see 2 sides to this.