The Separation Model – Part 13 – Data Storage vs. Data Display
It's SO, and I mean SOOOOOO, easy to cheat on the Data Separation model. You just add a little calculated field here and another over there - it's no big deal right? Actually, (my personal opinion) it's not that big of a deal. I mean "Really" you do have access to the UI file AND the Data file - "You're the developer!".
However, the situation may come up where these "extra" fields just clutter up things when some DBA wants to access the data via ODBC. So why not just keep it clean. The trick with this little problem is, what you show in the UI - for the user - is not what you're going to store in the database. This will happen quite a bit, and requires a different way of thinking than "I'll just add another calculated field."
The answer to this little problem is UI Utility tables. Sometimes, it's as simple as a tiny little table storing the names of days. Other times, it may be a complete mirror table which contains automatically populated data just for the purpose of showing calculated values.
To what extent you carry out the Data Separation model, is entirely dependent upon your willingness to keep things separate. It's my job to show you how you can do this - and that's exactly what this video is all about. The separation of Data Storage versus Data Display.
Comments
Multilingual day Names with a value list
You could have made the day names list multilingual if you had used:
ValueListItems ( Get ( FileName ); "Day Names")Instead of manually typing the day list in the custom function. So if you changed the value list it would feed back into the custom function. Also you can't blame laziness on that because I think that's easier than typing all the day names all over again ;)The problem with ValueListItems
The problem with ValueListItems is that you're hard coding the name of the value list "Day Names". However, using the ObjectID custom function which will use the internal id is a great solution for that.
Good tip!
-- Matt Petrowsky - ISO FileMaker Magazine Editor
Color chooser dialog
Hi Matt
How do you get the color chooser dialog to display, so the users can choose a color for the belt ?
It is not part of the demo files with this video....
Pushing it further?
Hi Matt
Thanks for the video! I find them inspiring stuff and love watching them, so apologies already for the somewhat "critical" questions that are following!
I was basically hoping that the video might introduce a way to keep the data file entirely free of calculation fields, but feel it fell a bit short of that, as it only refers to calculations that are based on generic values. Do you have any suggestions how one could take a similar approach to calculations that refer to fields specific to the table in question. To take a very simple example: all my solutions have the calculation field "Full Name" in the Peoples table, which is concatenated as First_Name & " " & Last_Name. Do you have a suggestion how I can remove this calculation from the "Peoples" table and place it in another file, maybe one specifically designed for calculations?
Also, what is the advantage of the technique you mention in your video as opposed to simply creating a popup field and using FileMaker's value list with two fields, day number and day name, but with only the second field being set to display? It would seem to me that this gives the same result using FileMaker's own resources and thus saves on having to create a custom function, a script trigger and two extra fields in the layout.
Thanks!
Calculations and the Data File
Hey Ballet,
Thought I'd chime in on the approach Matt takes (I'm sure Matt will correct me if I'm off).
It's hard to through a blanket rule over it, but for fields that are used only for display purposes, there are a couple of things you can do. My personal favorite is to make use of Merge Variables. There are some things you need to accommodate for if you are going to use them. But with a little effort you can create a displayed name without using any calculation field at all. Other options, you can use a utility table in the UI file that gathers and combines data from the data file. It's more complex and situational, but it can be effective if you work through a "standard" that you use consistently and is DRY compliant (Don't Repeat Yourself).
As for the popup field thing...there are some advantages to how Matt does it. I haven't really though the 2 approaches to see why I would choose Matt's approach over a simpler value list technique. Matt may have more insight on that. In the meantime, I'll have to think about it because I haven't used Matt's approach to scheduling as of yet. At first, it may be a slightly more complex setup...but I imagine it offers up some benefits that may not be readily apparent.
Josh Ormond
http://fmrift.wordpress.com
Josh Ormond