For this final section of the book, weve opted to provide for your consideration the standards our own custom development service firm, Soliant Consulting, uses. We do not want to be guilty of thinking that our coding standards are the only ones available, and if the struggle we had internally to arrive at a single standard is any indication, we e very cognizant that other approaches are entirely valid and effective. The important point in all of this is to adopt a standardany standard. On the other hand, we felt that a chapter on documentation and standards would be incomplete without presenting at least one concrete set.
Please know these standards are presented largely in their day-to-day undigested form without a great deal of exposition or details on the rationale behind the choices we and our organization made.
If you are interested in learning more about FileMaker standards, or in delving further into an excellent exploration behind why some of these decisions have been adopted, we strongly recommend you read the document that FileMaker Inc. itself has published on the topic (available free as a PDF download). To get to the FileMaker Development Conventions, go to the following site:
The authors of this book participated in the development of the FDC tech brief and believe that it serves as a comprehensive guide to standards in FileMaker.
Furthermore, in these standards we present the "Anchor Method" of managing the Relationships Graph in FileMaker. Roger Jacques, the initial creator of this approach (and a senior manager at Soliant), published an article, "Managing the FileMaker Pro 7 Relationship Graph," explaining the thinking behind the method in the September 2005 issue of FileMaker Advisor Magazine. An electronic version of that article is available, along with archives of all the magazines articles, as a subscription service on the FileMaker Advisor website:
We recommend that you include a copy of whatever standards youve used with a given solution so that a new developer to the project can review them if you are unavailable for whatever reason.
These conventions are compliant with version 1.0 of the FDC standards published November 1, 2005.
All conventions in this section are required in order for a file or files to adhere to the Soliant coding and development standards.
cbi_IndigoMain.fp7, cbi_Agents.fp7, and so on
z_TempError_gn (note the global denoted in the optional suffix)
_kf_contact_n (contact foreign key)
__kp_contact_n (contact primary key)
_ka_SelectedContactName_t (alternate key)
_kc_contactOrg_ct (compound key)
_km_contact_t (multiline key)
_kg_contact_gt (global key)
AcmeCRM_2005_03_15.zip Indigo_2005_03_16_PM.sit ApricotEBP_2005_03_17_1500.tgz
We encourage liberal script comments, but these are the minimum requirements:
Purpose: Navigate to Contacts Layout
Dependencies: (examples: layout name for context, script parameters, script variables, or plug-in requirements)
History: scl 2004 jan 01 (helpful to put the day last for quick editing)
Figure 27.7 shows a typical TOG.
Figure 27.8 shows the same information thats included in the list of TO names used in a number of dialogs within FileMaker. Note that they order themselves hierarchically just as they appear on the Relationships Graph.
The name of a TO describes the chain of source tables between the anchor and the TO itself, with optional attribute indicators. The attribute indicators can be functional names, names of keys, or any other means of clarifying the purpose of the TO. The ability to read a chain of TOs in both the graph and the various pop-ups and dialogs lends clarity. By reading the name of a single TO, one should be able to grasp where on the Relationships Graph it sits.
These are the rules that govern TO naming:
DIS__District__tog (or anchor)
The conventions in this section are not mandated, but they provide some standard ways of doing certain things, if you choose to do them.
If [// this condition is true //] Set Field [// describe set value //]
Keep your names as short as reasonably possible. Some dialogs are still width-restricted in FileMaker on Windows.
We use InterCaps for multiple words. Underscores are meant to differentiate between elements of a field (or table) name; however, user fields make an exception to that rule, where effort should be made to support ease of reading for end users.
Examples of developer fields that follow these conventions look like this:
Scripts may be subdivided into functional groups and separated by a header. Additionally, insert a single hyphen to appear as a separator. For example:
- ------------- FILE MANAGEMENT OnOpen OnClose Relogin for testing - ------------- ADMIN ACCOUNT FUNCTIONS Create New Account Delete Account
Spaces are acceptable in script names. Keep in mind that on Windows, some dialogs open only to approximately 4050 characters.
Part I: Getting Started with FileMaker 8
Using FileMaker Pro
Defining and Working with Fields
Working with Layouts
Part II: Developing Solutions with FileMaker
Relational Database Design
Working with Multiple Tables
Working with Relationships
Getting Started with Calculations
Getting Started with Scripting
Getting Started with Reporting
Part III: Developer Techniques
Developing for Multiuser Deployment
Advanced Interface Techniques
Advanced Calculation Techniques
Advanced Scripting Techniques
Advanced Portal Techniques
Debugging and Troubleshooting
Converting Systems from Previous Versions of FileMaker Pro
Part IV: Data Integration and Publishing
Importing Data into FileMaker Pro
Exporting Data from FileMaker
Instant Web Publishing
FileMaker and Web Services
Custom Web Publishing
Part V: Deploying a FileMaker Solution
Deploying and Extending FileMaker
FileMaker Server and Server Advanced
Documenting Your FileMaker Solutions