Tag Archives: GetFieldName

Blurring the Distinction between Schema and Data, part 1

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.

poe-600

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

Radical Separation, part 4

Disclaimer: This article contains speculative and experimental techniques that are in the proof-of-concept stage. Use at your own risk and test thoroughly.

FYI: In March at the Portland PauseOnError un-conference, Matt Navarre and I had a freewheeling Separation Model discussion, a podcast of which has just been posted as episode 85 at FileMaker Talk.

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.

6-9-2013 4-10-10 PM

Continue reading

Radical Separation, part 3

Disclaimer: This article contains speculative and experimental techniques that are in the proof-of-concept stage. Use at your own risk and test thoroughly.

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.

5-10-2013 10-41-51 AM

Demo Files:

Continue reading

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

Continue reading

Radical Separation, part 1

Disclaimer: This article contains speculative and experimental techniques that are in the proof-of-concept stage. Use at your own risk and test thoroughly.

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

3-20-2013 2-54-43 PM

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

Easy Sorting of List Views, part 3

Update 22 Jan 2013: Demo file and screen shots have been revised to fix bugs identified by Matt Ayres and David Schwartz (see comments at the end of article).

Ever since I posted part 2 of this series, I’ve been torn between, on the one hand, wanting to move on to other topics, and on the other, the realization that I wasn’t quite done with this one yet. So, here is what I expect will be my final posting, and final demo (dynamic list sorting, v3 rev5), on this subject.

Thus far, we’ve looked at various methods to facilitate dynamic list sorting (by “dynamic” I mean that the field to be sorted is determined programatically). Most of these methods use two fields — one of them uses four — and you can see them all in part 2.

But in the back of my mind has been the knowledge that Ugo Di Luca pulled this off with a single field back in 2004 (EasySort.fp7, shared by permission of the author, and previously discussed last April in an article entitled Portal Sorting, pt 3).

Continue reading

Easy Sorting of List Views, part 2

Well, I thought I’d said everything I had to say on this subject, but yesterday afternoon I noticed a glaring omission in part 1’s demo — what happens if the user manually unsorts the found set?

The sort indicator doesn’t disappear the way a good little sort indicator should. Fortunately this is easily remedied, thanks to the Get(SortState) function. Continue reading

Easy Sorting of List Views, part 1

Earlier this year, I posted a three-part series on Portal Sorting, and part 2 focused on dynamically sorting a portal when a column heading was clicked. Well, with just a few tweaks, this technique can be applied to dynamic sorting of found sets, and of course the most likely place to employ something like this would be on a list view.

I should note that on very large found sets, sorts using this technique can be noticeably slower than traditional “hard-coded” scripted sorts. (Performance is fine with normal found set sizes.) The benefit of using this technique, is that a new field can be added to a layout and sort-enabled in about 60 seconds without touching the script itself.

Continue reading

Avoiding Brittleness

Update 28 April 2014: Make sure to read the illuminating comments following the article, with various suggestions to make your code even less brittle.

The other day I was working with an OnRecordCommit script trigger — let’s call it “Trigger Script” — and, not surprisingly, I wanted this script to run whenever a record in a certain table was committed. Except… well… not exactly always… you see, there was this one other script— let’s call it “Other Script” — which had a Commit Record step right smack in the middle, and in that particular circumstance I definitely did not want Trigger Script to execute.

Luckily, we can include a parameter when a script is triggered, so I added the highlighted script parameter to the OnRecordCommit trigger as follows:

…which evaluates as 0 (zero) when the current script is “Other Script”; otherwise it evaluates as 1. Continue reading

Portal Sorting, part 2

The other day we looked at static portal sorting, where the developer decides in advance how the portal will sort, and “hard codes” those settings into the portal. Sometimes, though, we want to provide users with an interface where they can dynamically sort a portal by clicking on column headings…

…and we’re going to look at a technique to accomplish this today. Continue reading