Demo file: BillOfMaterialsDemo-v2.zip
Welcome to the first installment of a multi-part series on producing reports using the virtual list technique, or more properly, collection of techniques. Demo file: VLR-part-1.zip
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, but can) be represented and interpreted textually, either as records in a table…
The other day I had the privilege and the pleasure to give a POE presentation entitled Runtime Code, a.k.a. Blurring the Distinction between Schema and Data, in the room behind this window at the Ace Hotel in Portland, Oregon.
The overall goal of the presentation was to explore various ways one might move business or presentation logic out of its normal location in the schema layer, and into either a) the data layer, or b) some other, non-standard, schematic realm. An example of the former might be to store object names or calculation syntax as data in a table; an example of the latter might be to change the behavior of an object (e.g., a field or script) simply by renaming the object itself. Continue reading
Welcome to the fourth and final installment in our series on Radical Separation. Today’s article assumes familiarity with part 1, part 2 & part 3, and continues in the direction we were headed at the end of part 3. Specifically, we will finish up our exploration of “virtual calculations” by examing an intriguing approach suggested by Barry Isakson to a) reduce the field count, b) solve the “define more fields than you’ll ever need” problem, and c) accommodate summary fields, and I invite you to follow along in today’s demo file, Virtual Calculations, Part 4, if you are so inclined.
Today we’re going to delve further into the concept of virtual calculations, picking up where we left off last time, and with the assumption that readers are familiar with the material in part 1 and part 2 . We’ll look at some ways to make this technique less brittle (prone to breakage if objects are renamed), and also less opaque to DDR analysis tools such as BaseElements and Inspector. We’ll also see if the technique can be applied to auto-enter calc fields, and finally, we’ll explore some ways to make the technique easier to implement.
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
Earlier this month I had the honor and the privilege to do a presentation on the topic of Radical Separation at the PauseOnError un-conference in Portland, Oregon, which included a demo file resembling this one: virtual-calcs-part-1-v2
Before the conference I posted a pseudo-F.A.Q. which included the following…
- Q. What’s your experience with the Separation Model?
A. I’ve used it heavily over the last seven years, for a variety of vertical market applications, custom projects and, recently, on a vertical market FMGo app.
- Continue reading
So far in this series we’ve been looking at exporting data to Excel from a single table (Contacts). Today we’re going to extend the technique to encompass a second related table, Donations, and without too much trouble we can leverage existing work from earlier entries in this series (part 1, part 1.1 and part 2).
To avoid unnecessary repetition, this article assumes familiarity with the aforementioned predecessors, and you can follow along in today’s accompanying demo file, excel exports, part 3, if you are so inclined.
Today we’re going to take a look at streamlining the approach introduced in part 1 by reducing clutter on the Relationships Graph, going from this…
…to this, with no loss in functionality.