Zero to Awesome - Predevelopment Data Model
When FileMaker 7 was released, there was a new thought in town. That thought was "Ahhh, great, now we can separate the interface from the data." While this angle of attack was perfectly doable, it wasn't as ideal as some first thought.
It wasn't until FileMaker 8 came out with its support of variables that a lot of the "cruft" in a FileMaker solution was starting to be cut out. For the adventurous few, who used the separation model, sometimes shortened to SM, the advantages of reduced corruption potential and much easier updates were a big boon to using this approach.
Even I, was hesitant to use this approach because I knew of many "techniques" which were accomplished within just a single file. There is a very "filemaker way" of doing things when you've done them that way in the past. Letting go of this mindset, is something that requires a leap of faith when you've not used a separation model before. That's where this video will help resolve (hopefully) a lot of your [fears||doubts||concerns||questions] (pick a word) about this approach. This video will provide you with information about how to make things work.
As always, feedback is welcomed!
Comments
Bravo! Well done...
Excellent overview and discussion of the various ways to achieve disciplined implementations in FileMaker. Kudos to you for such clear graphics and revealing explanations! Lots of people should benefit from this.
Best Regards,
Theo
Separation Model #3
Hi Matt,
could you expand a little bit on the implementation details of model 3 (the one with the mid-level manager file)? I can't see how it may check what version of the interface file resides on a give client and replace it with the newest one if available.
I know that this may not be something that everybody might be interested in, but I think that on the Internet we've got plenty of too-basic example files that, while they're good for the purpose of presenting a technique in a simple manner so that everybody can grasp it, they leave big question marks when the very same techniques need to get deployed in real-world, tricky situations...
I dont' ask for all the gory details, only to be pointed in the right direction so that you can save some minutes of footage and I can figure the rest myself (which is the funniest part of the job, IMHO) :)
Keep up with the excellent job!
Regards,
Michele
The short answer is "Yes"
Yes, I will be doing a follow-up video on the details of how this works. While I won't be factoring it into the final series, I will be doing a video on it.
I need to create the visuals and the implementation does work.
There are always details about the deployment and development that may vary from situation to situation, but I agree that more details would be welcomed.
I'm working on it... Stay tuned.
Sincerely,
Matt Petrowsky
-- Matt Petrowsky - ISO FileMaker Magazine Editor
Using fonts in a multi-platform Filemaker solution
Hi Matt,
Your idea about using fonts localized to the actual platform is intriguing. You have selected "Lucida Grande" 11 pt. for Macintosh and "Tahoma" 11 pt. for Windows. While Microsoft have changed their preferred font from Tahoma to "Segoe UI" in Vista, it is probably best to stay with Tahoma, as a lot of Windows users still will be using XP (which don't have "Segoe UI" installed).
But there are some drawbacks with the proposed method. When the cursor is placed in a field, the font, size and style will be defined by the fields default font - and not the font, size and style defined by Conditional Formatting. First when the cursor exits the field will the Conditional Formatting definition take over.
If the default font is close to the Conditional Formatting font it is difficult to notice the difference. Defining Lucida Grande on the Mac platform will - at least in my case (using Vista) - set the default font on Vista to Verdana, which is rather close to Tahoma defined in Conditional Formatting. Therefor the font change switching between editing and browsing the field is not a big issue.
Due to this font change when setting focus in a field with a different font specified in Conditional Formatting, the benefit of localizing fonts in FileMaker to the specific platform is in my view - outweighed by the drawbacks - and can only be solved by FileMaker Inc.: They should allow developers to specify a font for each platform for each field. Or even better: Allow for a font conversion list, so a developer could specify, which Mac font should be be converted to which Windows (or XP and Vista) font and vice versa.
Until this happens I advocate using the font with closest readibility and similarity on Mac and Windows: which is Arial.
Verdana is the second choice. However there is a size difference between the platforms: Verdana 10 on Win is closer to Verdana 11 on Mac than to Verdana 10. (All comparisons done on Macintosh 10.5.1 with Parallels and Vista (KB9416449).
Best regards,
Mogens Brun
FMintegrator
Mogens Brun
Using fonts in a multi-platform Filemaker solution: A solution
Hi Matt,
I experimented with your idea about using platform specific fonts in a field and found a very simplel solution for doing font substitution between platforms for one font. Lets suppose we want to use Lucida Grande as standard for (most) fields and field labels on Mac while we want the same fields and labels appear in Tahoma on Windows.
If we develop on Macintosh we just have to specify Lucida Grande for our set of fields and labels. When we open the file on the Windows platform this fields and labels will be shown with "unknow" font. Never the less a font is applied, and that font is specified in Preferences/Fonts/Specify Font when you select "Roman" input type. To get Lucida Grande (or other or the platform "unknown" fonts) to be displayed in Tahoma, you only need to select it as the "Western" (same as "Roman" on Mac) input type on the Windows platform.
The same file has separate settings for input type for Win and Mac, so you can otherwise create fields and labels on Win with Segoe UI as font, and get it displayed in Lucida Grande on Mac if you similar select Lucida Grande here as the Roman input type.
Note: In a newly created file the default font used for fields and labels will always be the font defined in Preferences to be used for Roman/Western input type.
Conslusion: Platform specific font selection can be performed between one ( and only one) font to another font on the other platform - if the first font is “unknown†to the other platform. And vice versa.
The drawback is of course that some fields and labels will show "unknown" font on the "other" platform, but as long the developer knows the rule it should have no practical consequences for the users.
Note about Tahoma on Win: If you create a file on Win and selects Tahoma as main font, you can't get that converted to Lucida Grande on Mac, because Tahoma is a known font here. So if you want a change between Lucida Grande and Tahoma you must definitively develop on Mac. Most developers with concern for fons do that anyway!
Best regards (I mail you directly a test file you can experiment with),
Mogens Brun
FMintegrator
Mogens Brun
"Manager File" reference
In Predevelopment_DataModel_Full.mov you mention a technique of using a "Manager File" and indicate this was first discussed in detail in 2004 and that the principles still apply. I haven't found a link to it, nor does searching for "Manager File" bring it up.
Is it available? Would appreciate a URL.
Kind regards,
Morley Chalmers
--
Do not worry if you have built your castles in the air. They are where they should be. Now put the foundations under them. -- Henry David Thoreau
Morley Chalmers
--
Do not worry if you have built your castles in the air. They are where they should be. Now put the foundations under them. -- Henry David Thoreau
References
Hi Matt,
Really enjoyable and intriguing video about the separation model. Can you recommend any references for more in-depth reading on how to construct model 3? It sounds like a very good way to go, but it's very hard to figure out exactly how to start and troubleshoot the model to end up with something that works. Thanks for all your hard work!
Cheers,
Bob