Just my writeup
8 Likes
There is such a huge amount of change in this version. It's a stand-out.
3 Likes
and I didn't mention the small changes. There are really many.
1 Like
@WimDecorte wrote a nice blog post:
and I also wrote something:
2 Likes
Trying to wrap my head around the GetPersistentData ( name ; instanceID ). Right now I have a table called "settings" with a bunch of things like "startOfSchoolYear" "endOfSchoolYear" and "listOfHolidays" and "listOfSchoolDays". "listOfSchoolDays" is a slower calculation that removes weekends and holidays (including snow days which show up mid semester and change the last day of school) I go in nightly and fill these in in the settings table, and then when a user opens Filemaker it sets $$listOfSchoolDays to the item in settings.
Am I right in understanding that GetPersistentData ( name ; instanceID ) is "the modern" way to do that? And I could (for example) just a have a simple script that gets a list of them all and turns them all into $$globalVariables, or maybe something smarter than that which only makes "some" of them global variables.
If it was as fast as a variable (which hopefully it will eventually become) it could replace them completely in these instances, right?
GetPersistentData is not a global variable.
You will still have setting tables.
This is for embedding data in the structure like templates for CSS, HTML and JavaScript. Or maybe an base64 encoded logo.
And you can't store secrets there as people will see them in Save as XML.
if the user is supposed to update this, you may still use a field.
2 Likes
ok makes sense.
There is a big overlap in the capabilities of persistent data and global variables. For that reason the use cases are also going to feel similar. When I first heard about them, it brought to mind Value Lists. They are also "global" within a file and they also do a task that could be done with tables. Admittedly the use case for Value Lists is narrow: present a set of records to the user. But in the background, it's a file-specific, global store.
In your example you have to calculate school days every night. Is there any advantage in switching?
The examples provided in the documentation is suggesting that they are intended to replace on-layout text objects or single record tables which store code for webviewers and add-ons. I can imagine scenario where the developer provides themselves with DEV_ONLY layouts that provide them with tools to view and add persistent data as a initialisation or periodic update.
1 Like
Although first load speeds will be relatively slow (some indications are 7x slower first load, then cached), this could be used a a global variable across all sessions (unlike a traditional global that is session specific). May not be the best or most appropriate use case, but it is a possibility.
I'm sure new use cases will appear to go with this new capability.
I think my general rule for Persistent Data is: Use Tables+Fields for data and Persistent Data for schema. So very much in line with what @MonkeybreadSoftware said. If i configure a webviewer widget, i'm happy to store the html/css/js in persistent data. Or if i version my software releases, I could store the release version string in persistent data ("2.0.1" eg). Or an app logo, that is the same for all copies of the file.
I most likely won't use this feature for deployment or customer-specific information/data, or configuration/settings. Tables are fine for that.
1 Like