Disclaimer: This article contains speculative and experimental techniques that are in the proof-of-concept stage. Use at your own risk and test thoroughly.
In part 1 of this series, we defined radical separation as a separation model scenario in which the developer no longer has access to a data file once a solution had been deployed. Updates to the solution are delivered in the standard separation model manner: by swapping in a new interface file.
We explored the concept of “virtual calculations”, where certain (unstored) calculated fields in a data file derive their definitions from syntax stored as data in a special table in the interface file. The advantage of this being that calculation logic can be redefined programatically by the simple expedient of replacing the interface file.
In the six weeks that have gone by since I posted part 1, I have made a couple improvements to the technique, one of which which we’ll examine in today’s demo file: Virtual Calcs, Part 2
Today’s improvement is that fields using virtual calc syntax can now be named as you please, as opposed to requiring a unique number as part of the field name as per this screen shot from part 1.
Of course, if you’re using virtual calcs primarily as a way to bring new calculated fields online at some unspecified point in the future to address some as-yet-undiscovered need, then in a radical separation scenario, it will be too late to give the field a meaningful name.
But virtual calcs can be used for any unstored calculated field, not just “reserved” ones you’ve predefined for future use… so now this gets more interesting, because it means existing unstored calcs can be redefined as needed, even though the data file is untouchable.
So, I didn’t want to lose the robustness arrived at after much trial and error in part 1. But I wanted to break free from the onerous requirement that every virtual field contain what amounted to a unique (per table) serial number, embedded in the field name as per this screen shot from part 1’s demo:
I would still want to set aside reserved virtual calc fields for future use, but now I could name them in a way that made more sense, e.g.,
At any rate, I knew that I wanted virtual calc fields in a given table to use their own name as a “key” of sorts, to derive their syntax from a global field (zzVirtualCalcDefinitions) sitting in the same table. And this global field would be populated via a scripted loop that would “walk” the virtual calc definitions table in the interface file. (Also, this global field would no longer need to be a repeater.)
I considered using XML, but that seemed like overkill. But what about a simple pair of “tags” for each field, resembling HTML open and closing tags? Something like this?
…which would be produced by walking the VC definition table in the interface file…
…and interpreted by virtual calc fields in Donors or Donations like so (all calc fields will be defined identically, except the calculation result type will need to be set appropriately):
Thanks to the GetFieldName function, each virtual calc can parse its own virtual definition from the local zzVirtualCalcDefinitions global. So far, I’ve been very happy with this method, though of course the disclaimer at the beginning of this article still applies.
Well, that’s it for today. In part 3 we’ll look at further refinements to this technique.