Effective Solution Settings
Every solution starts out like an infant. It knows very little and works hard to manage your solution's data as it becomes a productive citizen of your digital society. As it grows, your solution will need to offer a variety of options. User A prefers things one way, while User B another.
Your job, as the developer, is to accommodate those whims and preferences, or settings as we’ll call them, in the most efficient way possible. As is somewhat typical, you may be halfway through development when you stop and ask yourself if there's a better way to manage the growing list of settings.
In this video, I showcase an effective method for managing solution settings. By combining popular FileMaker techniques, we can consolidate, present, and manage settings in a highly streamlined way. Whether your solution is decades old or a brand new build, there is always something new to learn about handling data. We will look at how to combine JSON with solution settings and how easy it can be to simplify the process.
Comments
Your Favorite Toggle Button Trick .. not so refresh.
Using the file; loading the $$SETTINGS; creating a button named "button" that has a single step of ...
Refresh Object [ Object Name: Let ( [ ~value = not GetSetting ( "layout. 12. ruler. show" ); $$SETTINGS = JSONSetElement ( $$SETTINGS ; "layout. 12. ruler. show" ; ~value ; "JSONBoolean"] ; "button"); Repetition: 1 ]
Additional code on button:
Conditional Formatting for Selected Objects ...
Formula is GetSetting ("layout.12.ruler.show")
Why doesn't this button refresh correctly?
GetSetting() is read ONLY
As mentioned in the video, the GetSetting() custom function is read only because it uses ExecuteSQL, which does not support writing to the database.
If you want to update the settings when changes are made, then you need to create scripts or other custom functions which will write the values back into the database.
Without using a plug-in, you'll likely be using a script that will do this. You'll have to 1) Go to Layout, 2) Find record with key, 3) Set Field to value field to update.
My preferred solution is to use a plug-in and I use MBS plug-in to use it's SQL functions (independent of context) to directly write to the table.
Another more current option is the use the Execute Data API script step in FileMaker 21+.
-- Matt Petrowsky - ISO FileMaker Magazine Editor
User specific settings
Thanks again, I really like this solution.
I wonder what would be the better solution for 100-150 user to save individual settings.
1, Save the values that are different from the default in this table, but associate with the user OR
2, Use this table for only solution wide settings and have the user specific ones in the User table, in a field as text. Evaluate it after the defaults, so they overwrite them.
My approach would be...
IMO any preferences specific to a user belong in a Users table in their own dedicated field with read/write access controlled by the privilege set.
In order to centrally manage, but still co-mingle user specific preferences I would either a) "tag" (using the section - or - another field) which settings are, in-fact, user specific. Or, better yet, contain all user specific settings within a top level "user" key.
I would then create a preference iterator function. Using either a While or Scripted Loop I could walk across the user preferences and compare them against any defaults.
For further clarification, using a top level "user" key where something like "user.layout.12.view" where this might default to "form" and then as stored in the Users -> prefs field it would likely be stored as JSON and would override that key because the user had switched it to "list".
Hope that helps.
-- Matt Petrowsky - ISO FileMaker Magazine Editor