Overview
As a best practice, for the sake of both network efficiency and enhanced security, it is suggested you create one (1) empty table with no fields and one (1) blank layout and name them such that it identifies the table and layout as the file startup elements.
Background
FileMaker, by nature of being a fully encompassing database platform has made it easy for developers to quickly create solutions to everyday business problems with less development investment as compared to other technologies such as MySQL and PHP based solutions. While this is an incredible benefit, it also opens the door for coding practices that are resource intensive. The "Low Impact Startup" best practice is preventative medicine for the developer before such issues arise.
The fundamental issue is the difference (and implied separation) between the client UI and the data structures used to support the collection of data and application of relevant business rules on both the data and UI. With careful practice a developer can separate these two topics to provide excellent user experience while maintaining the ability of a FileMaker server to process and serve the data used to populate it in a timely manner.
Implementation
The blank layout should be associated to the empty table, and should be the selected layout for the Switch to layout: check box within the File > File Options... settings.
Using the Perform script: setting, within this dialog, is the preferred method for arriving at any default target layout for solution startup.
Both the Table and Layout should be the topmost listed items in Manage > Database > Tables and Manage > Layouts.
Reasoning
Reduced startup overhead is realized when the layout is ensured to be local to the file (meaning it is not accidentally or intentionally associated to any external files). This also ensures the file is opened to a known location with a low load impact, because graphics and other elements are not loaded until navigation takes the user to the target layout based on the client being used (FileMaker client vs. FileMaker Go).
Prevents the accidental last layout issue because FileMaker remembers the last viewed layout when the file was closed as a locally opened file. This means the file, when opened over the network, without the Switch to layout setting set, would default to the last viewed layout.
Avoids accidental External Data Sources from being opened if the last viewed layout was based on an external data source.
Provides supplemental security to the file, in that the startup layout and table contain no fields or elements which are immediately accessible.
Empty Startup Table
Blank Startup Layout
Startup Variables
Using a simple text object on the Startup layout can optionally be used to load data into global variables. By utilizing FileMaker's conditional formatting on this text block, any number of global variables can be initialized. The biggest advantage to this implementation is centralized initialization of global variables - instead of potentially be spread across multiple startup subscripts. The conditional formatting code reads as follows.
EvaluationError ( Evaluate ( Self ) )
The text block is preferably situated in the right hand portion of the layout and anchored to the right. By providing a left based indent on the text block, a small portion of the text block should transverse the layout's right most boundary. This will ensure the evaluation of the conditional formatting.
See the Standards Template File for FileMaker 12
Startup File Options
By using the low impact startup layout within the File's options, the file is always guaranteed to open with minimal impact. It is loading a table with no fields or data. Using the Script Triggers within the File's Options and a dedicated startup script is the preferred method for targeting the proper initial layout for the solution.
11 Comments
Matt Petrowsky
I think this is a great idea for Best Practices. I don't know that it should be a standard because there are so many different situations where FileMaker is used.
For example. I don't personally have the network issue because I'm doing a shrink-wrapped solution. Then you also have cases where FMP is used for kiosk development.
Granted client/server is the predominant use of FileMaker, but this would be more of a best practice to me.
It's also a great idea for mobile development!
The name of "----" is a bit cryptic to the first time reader, so I would suggest a reserved element name for this best practice. We can set these reserved names in the coding standards and refer to them in Best Practices
Perren Smith
Hmm...I still think it applies not only to server solutions, but standalone as well - shrink wrap or kiosk style.
It provides a supplemental (read: not guaranteed!) security mechanism to use when scripting the onFileOpen trigger no matter the environment of the .fp7 file at hand.
Yes, we all know that it is possible to breach onFileOpen triggers in the right set of circumstances, but this at least allows for elevating access based on starting at the default of "I can't do anything: I've got no fields, objects or records to play with. Now what?"
This is similar to PHP before one makes a connection to a DSN - what's the standpoint of the user at point of entry and do you want them to potentially play with the data in the table you default to? I don't.
The naming of "--------" is identical to the separator for both Manage > Layouts and Manage > Scripts. It's reserved in that sense anyway and this is just an extension of that. FileMaker will throw warnings when creating a table with this name so you know it's not intended to do anything other than act as a developer aid.
Matt Petrowsky
I'll need to implement and look at it to see if I would consider it a standard.
For me, the best practices we are creating are all things I'll be doing in my own solutions thus far. It's likely that we're on the same page about things like this. I personally just need to spend some time with it to become familiar.
From just reading your text I didn't see the advantages which you have now further clarified in your above comment. I'm seeing it as a security and network speed advantage.
Perren Smith
Oops...I didn't frame my reasoning quite right...although it still may land this in best practice.
Take a multiple file solution for example. Customers.fp7 and Orders.fp7.
In Customers.fp7 I have a navigation script where I use the steps:
What happens if the last layout I modified in single user mode was based on the Order Items TO or some other TO that was auxiliary to the solution? It would bust...doesn't matter if it's hosted at this point or not.
It's more of a prevention technique against others modifying scripts in the solution down the road assuming a file referenced as an External Data Source will always behave in a certain way, i.e., opening to a certain layout ( and supporting TO ).
Maybe the coding standard is always to use a Go To Layout after using an Open File script step to ensure proper context.
Matt Petrowsky
Also note that the actual name of the layout is simply "-". View under Layout > Layout Setup... or double-click in Manage Layouts.
This is a behavior of FileMaker which has been carried forward from previous versions - which has obviated their use (to some degree) by the new support for layout folders.
In fact, if you create folders in FileMaker 11 and then open in FileMaker 10, you see the folders are actually still internal layouts which are identified in FMP 11 as folders.
Also, creating a script with just a dash will show up in the Scripts menu as a divider.
I would still opt to name the table something that represented what it does and simply set the name aside as a reserved element name. STARTUP for example. While using UPPERCASE does not follow the convention of Tablename, this would be a best practice and STARTUP as a table could be a reserved element name.
Jeremy Bante
This does seem like a Best Practice more than a Standard. This whole wiki is still at a nascent stage, so we only have "I know it when I see it" to tell the difference, which is too bad, but it'll do for now.
Perren Smith
Fair enough. Best practice is still better than nothing. I'll take it. :)
Thanks,
--Perren
Matt Petrowsky
Oh, and one other thing. When you specify a layout within File > File Options... you can't specify a layout which is a separator.
Perren Smith
Oh sure...rain on my parade. :) Well, I suppose we should dig for the "magic" name that satisfies all the problems at hand. I'm sure I'll have more perspective this month as I'm working on a project that directly relates to the subject at hand.
Matt Petrowsky
Perren, I'm not sure we need all the Background info on best practices. I left it there for now, but it reads a bit ambiguous to me.
It would be nice if we could keep the Best Practices very succinct and useful.
I think most people using FileMaker know that it
I'm not focusing on this just to be mean, rather, I'd like to keep the extraneous out of the pages themselves. We can do this in the comments or in the blogs area. Did you know you can create a blog page and then link to it?
You guys should feel free to use them, just know that they are public too.
Try to be as literal and specific with your page content as possible.
Anonymous
I've used 'Null' for table and layout with nothing. I think that clearly describes it. But I like STARTUP even better. I ended up putting description of why the layout & table exists right on the layout itself and use conditional formatting to hide it unless in layout mode. And then I added a note in the graph right behind the Null table also explaining it.
It is too bad that tables do not have a comment like fields do.
BTW, I love this Dashboard website, concept, developers who respond, ideas, suggestions. Thank you all for providing this for us.