Welcome to filemakerstandards.org
This web site and the coding standards presented here are for developers using the FileMaker Pro database software application. They are maintained and documented by a core group of contributors familiar with developing FileMaker Pro applications.
There are two primary aspects covered on this site. The first is a Coding Style Guide and the second is Best Practices. The information provided is being cultivated in order to facilitate "clean reading" and well functioning FileMaker solutions. Please note that this site is not attempting to promote a solution "framework". While we do provide a starter file, the use of the documented best practices is obviously voluntary to the extent which it will benefit anyone who is able to reference the documentation maintained on this site.
Disclaimer: These are not official standards from FileMaker, Inc. (read the Background section for more info)
Coding Style Guide
- Background
- Coding guidelines
- Indenting and White Space
- Naming Conventions
- Boolean results
- String Concatenations
- Operators
- Function Use and Declaration
- Control structures
- Calculation Variables - Let() function
- Empty strings
- Commenting
- Layout references
- Relational Graph Organization
- Reserved elements
- Scripting and Organization
- Getting Involved
Best Practices
This site also provides Best Practices for a wide variety of common FileMaker coding situations.
You may also be looking for the Standards Template Files.
Special note
These coding standards are based on developing a FileMaker solution for use within the FileMaker client/server architecture. They prioritize considerations of that architecture over compatibility or ease of use for other FileMaker supported connectivity methods including Instant Web Publishing, Custom Web Publishing, FileMaker PHP API or FileMaker Go. You will see the use of various ASCII characters beyond numbers and letters, such as the percent sign (%) and tilde (~), within these specifications that are known to be discouraged in use with other FileMaker connectivity methods. It is assumed that, as a developer, you are using FileMaker Pro Advanced for developing your FileMaker solutions.
Please visit this page for reference on URL character encoding issues from the IETF and how that may impact alternative connectivity methods to a FileMaker solution.
If you are creating a distributed solution across the variety of platforms supported by FileMaker Pro, it is suggested that you deploy a unique file for each technology. For example, use one file for primary solution data, one file for web publishing, one file for FileMaker clients, and one file for mobile devices (unless providing for multiple mobile platforms dictates otherwise).
15 Comments
Anonymous
I think having some type of universal standards like this is a great idea and I like the way you have organized this site. I am a little confused and a little hesitant to adopt most of these standards however. My reasoning is because as the note on the home page says, these standards do not have compatibility in mind. I often times will integrate websites with my databases as well as using ODBC and SQL.
Some of the special characters being used in these standards will definitely be problematic in these scenarios. It seems to me that developing a standard that does not prioritize compatibility with other systems is a huge mistake. Especially as web technologies are being integrated with filemaker more and more.
I realize I could create a separate file for the web and iphone etc but then I would be breaking from the standards on that file, wouldn't we want all of the files we create to adhere to these standards? Wouldn't we want to prioritize compatibility and readability rather than only readability?
-Tanner
Jeremy Bante
Nobody's perfect, and the balance of compromise will continue to evolve in perpetuity. Other conventions from Core Solutions and FileMaker do take interoperability as a higher priority. Many systems will have to deviate from the conventions here to satisfy technical requirements, and that's OK. The standards aren't perfect, they only aspire to be; and, in turn, I think it's often appropriate to aspire to the spirit of the standards rather than follow them exactly. Do what you need to do to get your stuff done, but hopefully the standards can at least give you plenty of good ideas.
Matt Petrowsky
Well said, I was a bit verbose.![(smile)](s/-ibnava/8804/1nmz4ib/_/images/icons/emoticons/smile.svg)
Matt Petrowsky
I'm all for the ideal. The biggest problem in the path of an ideal, that satisfies all the various environments, is FileMaker itself.
Sadly, my BIGGEST gripe against FileMaker is the SERIOUS lack of organizational/documentation tools. I think FileMaker has been one of those applications which had a lot of early adoption, started heading in a direction and hasn't taken the time to re-factor.
Here are only some examples of what I'm talking about.
Granted, recent improvements like the Inspector palette and improved Status bar provide more information, but there is still a ways to go in aiding the developer.
So why say all of this to address why I promote breaking out the various technologies on a file by file basis? Because, if you're seriously developing a FileMaker solution then you're likely using a separation model. In this case, the data file is clean and won't be hindered by FileMaker specific conventions (such as the tilde and percent). Accessing with ODBC/SQL shouldn't be an issue.
I agree, this does add a bit of overhead (due to potentially duplicated script functionality), but the upside is that your whole system becomes a bit more self-documenting.
Some day, I'll have to sit down and document my development philosophy with FileMaker. I'd love to have a public chat about it. I'll make blog post about it and we can carry the conversation on over there.
* FileMaker, as the "easy-to-use" database is great. The problem for advanced developers is that it's a bit of dialog hell.
Anonymous
I think that would be a great idea for you to write up a blog post. I definitely think it needs to be discussed further. I still don't think that I am convinced that it is worth following standards that I have to intentionally break from as soon as I start publishing data to the web (which is most of my solutions). I really do see the value here and I agree with most of the things that have been said I just wish that some of the crazy special characters were left out so that these standards could be adopted more widely in all filemaker files that I will create. I realize these will evolve over time but from my perspective they are already hobbled from the start. I want to use a naming scheme that I don't have to think every time I am naming a field "will this break on the web?" or "will this break an ODBC import?".
It just seems like so much more work if I need to come up with yet another convention for creating files meant for web data or files meant for iPads. Why not just go to the lowest common denominator and make it work for all 3 scenarios? Obviously you need to use different coding techniques in these situations but why should we need to change our conventions?
-Tanner
Jeremy Bante
Why don't you post a Proposal? Also, Matt put the blog post here.
Matt Petrowsky
I can see your point in wanting to do everything in one place or one way - because it can be. I personally used to follow the same approach - everything in one file. However, this is what drives me to use more compartmentalization these days.
"Exactly" is what I would say. Creating something for a mobile device has its own constraints, as does coding something for the web.
To the extent you might want to have all the "guts" in the same file, which I'm personally opting against (in favor of dedicated files with shared data), you can always modify the standards we've got started here.
Just the other day, I did a super quick test, and it's a great idea if you want to keep everything in the same file. My test was to "webify" a single file solution, which uses these standards.
It's as easy as selecting your whole TOG (Table Occurrence Group) and holding down option (Mac) or control (Win) and dragging to make a copy - yes, of the whole TOG - not just one TO.
From that point, I would then rename TOs from FunctionalArea » Basetablename to FunctionalArea_Basetablename for use within the web portion of the app. If you're using clean datafieldNames, then characters like % and ~ are not going to impact you. Percent is only for FileMaker specific display. You're hopefully using the intermediary language (predominantly PHP) to manipulate data for display for the web. Note: I'm not really considering IWP a real solution when it comes to these standards.
This is a good thing to do, as far as I understand it. The few solutions I do have which share data to the web and are accessed via FileMaker used shared elements. I'm ALWAYS afraid I'll break one when I make changes in the other. "If I rename a TO, is it hooked up statically within a PHP file serving to the web?" Not even having questions like these is ULTIMATELY freeing and part of the goal of these standards.
As Jeremy pointed out, a great idea would be a Proposals related to variants. Or even better, let's get some pages on here about the things to watch for when doing ODBC or Mobile. I've personally not used FileMaker as a backend for web stuff a whole lot because I opt to use a system like Drupal.
We're always looking for people who are going to take a proactive role on this site. Anyone want to become the voice of FileMaker for Web Standards? FileMaker for Mobile Standards? Try Getting Involved
Anonymous
Not to beat a dead horse here but this is exactly what I am talking about:
"From that point, I would then rename TOs from FunctionalArea » Basetablename to FunctionalArea_Basetablename for use within the web portion of the app."
Why not just start with FunctionalArea_Basetablename in the first place. That is all I am saying, why the fancy character? It achieves the exact same result without sacrificing compatibility and you don't have to make any concessions to your conventions or remember to make any changes depending on the file you are in. I will try and sign up to contribute on the site but I think that is essentially the statement I have been trying to make.
I totally agree with everything you are saying, I just think there is a better alternative to using percent signs double arrows etc in our schema.
-Tanner
Matt Petrowsky
I see what you mean. The primary reason for characters like the » is for code readability. Within complex calculation code...
Becomes much easier to read when compared to...
The double chevron becomes a dead giveaway about the TO within code and since FileMaker can support Unicode characters, we've opted to take advantage of them. At least to the extent that we've stated that these standards address the client/server aspect of FileMaker's technology offerings.
It is for these reasons that we've opted to use these characters in these standards. Yes, I will agree that some of what we are doing "feels uncomfortable", however, I think those of us who are adopting them are finding some distinct advantages (at least I hope - otherwise I'm just basically documenting a grand FileMaker experiment)![(wink)](s/-ibnava/8804/1nmz4ib/_/images/icons/emoticons/wink.svg)
Anonymous
I can definitely see the advantage of readability in your examples. I think I have some contemplating and experimenting to do. Keep up the good work. It is helpful to see things from someone else's point of view.
Perren Smith
Just for fun the URL encoded equivalent of » is %C2%BB. :)
Perren Smith
It took me a while to get used to using high ASCII in these areas as well, being recently tossed into the world of WPE compatibility at my day job.
All I can say to that end is this is exactly why I advocated for separate WPE, FMGo, etc. access files. Many of my end users and others who script will never go near these files where I can stick to core best practice for the masses, yet I can adopt alternative conventions to make life easier on the web integration components.
Also, technically it is possible to use these characters in URL encoding and not have WPE break, it's just more of a pain when working in PHP to adapt...ugh.
Anonymous
Yeah, unfortunately (or fortunately) I am not doing any work in WPE, any web stuff I do is in PHP. So that has been my perspective on this. I haven't done a separate file for my PHP data yet but maybe I will have to give it a shot the next time I make a solution. At first glance though it does seem to add a lot more work though. I will need to duplicate all necessary table occurrences into that file and set up any relationships necessary for displaying calculations or portals. There may also need to be scripts that are duplicated if I run any scripts from the web. So much of it seems like duplicated efforts. But maybe the readability and organization aspects will make it worth it. Now I just need to come up with a new project to try this on.
Anonymous
By the way, is there any way for me to not be anonymous? Can I get a profile or account on the site?
Thanks,
Tanner
Matt Petrowsky
Tanner, we'd love to get others involved. Please read the section about Getting Involved