Radical Separation, part 2

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.

5-2-2013 9-09 PM

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.

5-3-2013 10-06-29 AM

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:

5-2-2013 11-08-35 PM

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.,

5-3-2013 10-31-30 AM

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?

5-1-2013 6-01-31 AM

…which would be produced by walking the VC definition table in the interface file…

5-2-2013 11-33-54 PM

…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):

5-10-2013 11-55-33 PM

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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s