The Separation Model – Part 1
After spending close to two decades working in FileMaker, I'm always amazed there's more to learn. Even to this day, I come up with new ways to utilize FileMaker.
Recently, I started working on a project for a local Karate School. They're just like any other small business, which ends up with a copy of Microsoft Excel and has more needs than the number actual spreadsheets they manage. Of course, we all know that keeping random bits of information in various spreadsheets is just terribly inefficient. So what's a FileMaker developer to do?
Well, this developer just had to solve the problem and use it as a great example to talk about a variety of development techniques and methods. This video is the first video in a series which will focus on the ground-up development of a new FileMaker 11 solution.
Whether you've been working with FileMaker for many years or you're just now getting back into things, this short video series should have a number of things which will help you become a better developer. This first video starts with the benefits of the separation model and how planning a data strategy is a critical step in the whole process.
Comments
Swapping out the interface file.
Matt,
As part of this series, could you show the steps in the process of swapping out the current interface file with one that has been updated.
Thanks
Always build our databases this way?
I had a question come into our support system and I decided to answer it here...
Q: Question regarding the Separation Model. Is it better to always build our databases this way? One file being the interface while the other file holding our data?
A: This really all depends on your deployment and future plans. If you know you’re only ever going to use FileMaker Server (or peer-to-peer) access of the FileMaker file then keeping things in one file makes it much easier. If your solution is going to be very simple and won’t tend to grow to the degree that things could become hard to manage, then you’re probably fine there.
However, and this “however” depends on your comfort level, if you’re going to integrate multiple platforms (e.g using both FileMaker clients and Mobile Go), or if you’re wanting to squeeze every bit of performance out of the client machine then having a “local” UI file which accesses remote data can be a big benefit. Of course, the file doesn't have to be on the client machine/device, it can be on the server too.
Remember, data is stored as a bunch of bits. When they’re floating around (<wink> they don’t really float </wink>) on a hard drive, any given FileMaker file doesn’t care where they come from. When you separate your data from your presentation you gain an instant level of clarity in that pretty much everything in your data file is just data - whereas your interface file (or files) can be as crazy as you want.
Another advantage is being able to segment your solutions. Different people in organizations may need differing types of presentation of that data. When you build this all into one file you’re adding many levels of complexity to the solution. Compartmentalization makes it easier to mange and maintain code. I'll do my best in this series to point out where you gain advantages to doing this. The "extra" work really isn't that much - it just "seems" like it is.
-- Matt Petrowsky - ISO FileMaker Magazine Editor
sample file
Matt
Why no sample file to download?
Its coming
I was going to wait to release the file to make sure it had good internal documentation, but I guess I could put the iterations up here on the site. It's my perfectionism. :)
-- Matt Petrowsky - ISO FileMaker Magazine Editor
Sample
Thanks, it makes following video much more useful.
filemakerstandards.org StartFile
In both movies you're talking about the standards used througout this solution.
You're talking about a template file available on the website of http://filemakerstandards.org.
I'm already using those standards for a few month now but I can't find that template to download. Am I missing something?
Thanks Matt keep up the good work!
StartTemplate
Thanks Matt for adding the technique files :-)
I like your developer layouts
My biggest takeaway from this video is how Matt designs and maintains his developer layouts. Very handy for team development!
Just one warning for everyone: Never use developer layouts in scripts. I have had a lot of troubles with that in the past, for example because certain things do not work in table view.
Since I had these problems, I strictly use dedicated kinds of layouts:
I also suggest you never ever put summary fields on developer layouts (unless you add them to a hidden-by-default tab of a tab control).