Blurring the Distinction between Schema and Data, part 2 | FileMakerHacks
This is Part 2 on Kevin Franks presentation at Pause on Error recently:
A recurring theme, as we saw in part 1 and will see again today here in part 2, is that you can store “runtime code” as data. The most extreme example I’ve encountered is a proof of concept created and presented by Dr. Ray Cologon at DevCon 2006, the Text Script Interpreter, a.k.a. TSI.
The idea is that the entirety of FileMaker scripting can (not should, butcan) be represented and interpreted textually, either as records in a table…
As with the first part, these ideas are for those wanting to push the limits of mixing schema and data, and require changing how you think about programming with FileMaker. The benefits include much stronger (less brittle) code that does not break when changes are made to the pieces like layout name, script name, etc. Another benefit, for example, is that the same button on a layout can be used to do multiple functions.
The main parts of today’s post are:
- Recreating ScriptMaker
- Performing script via Open URL
- Script Name or Script ID?
- xmCharts (Hard Coding vs. Dynamic Coding)
- Faux Merge Fields
- User-Friendly Excel Exports
- Virtual Calcs
There are plenty of downloadable examples at the link, and plenty of links to other posts containing more information. Set some time aside to study.
via Blurring the Distinction between Schema and Data, part 2 | FileMakerHacks.