Reciprocal Linkage, part 2

This is a quick follow up to last week’s article on reciprocal (bi-directional) linking, and will assume the reader is familiar with that material. Paul Jansen of APJ Computing Solutions sent in a revision of one of my files demonstrating that, among other things, the graph could be a good deal leaner (as per my stated goal of making the approach as simple and lightweight as possible), and I am sharing that file today with his permission, along with my own attempt at further simplification.

Demo Files

• reciprocal linkage with uuids (APJ v2)
• reciprocal linkage (KF v2)

Paul Jansen’s Demo Notes

In looking at how the original demo works, I was prompted into thinking about using a Card window instead of an offscreen window. In the past, I have avoided using additional utility windows, but the release of FileMaker 16 with SDI on PCs and the option to specify a layout with the New Window command has prompted me to review their potential.

It seems to me that rather than hiding these windows off screen, we can make use of them to indicate progress and as a replacement for custom dialogs. I have included both these features in my modified demo. It seems to me that showing some kind of “something is happening” dialog/card window reassures users that something is happening and reduces the chance of random clicks due to impatience (in fact it prevents interaction with the background window). My testing indicates that for quick scripts like ‘Make Link’ in this demo, neither card or dialog windows will actually draw on the screen, so I added an artificial delay to demonstrate how the utility window can be leveraged to indicate progress.

Attached is a revised demo that makes a feature of the temporary windows

• Choose card or dialog window depending on FileMaker version
• Use a dialog/card window as a progress indicator for ‘make link’
• Use a dialog/card window instead of the custom dialog for the ‘break link’ script
• The ’make link’ script currently has an artificial delay to simulate what might happen on a slow hosted solution.
• With Debug on, the script pauses at the dialog and has a popover to check IDs

If I were doing this for real I would probably have more script parameters and make the card/dialog window have more data driven control (button labels for example) rather than just using hide conditions.

Kevin Frank’s Demo Notes

I cleaned up the graph, and went with Paul’s idea of navigating to the join table and issuing a New Record command, as opposed to creating the join record via Set Field as per my original approach… although for reasons of backward compatibility and simplicity my demo uses an off-screen document window rather than a card window.

Once I’d dispensed with creating the join record via Set Field I realized that I could eliminate the key_combo field from the join table, so that table now consists of a single field:

I was also able to dispense with the global equivalent, g_key_combo, in the doc table, so that table now consists of two fields only: id and name.

Both the “make link” and the “break link” scripts were updated… for “break link”, note the two highlighted steps, as well as the comment on step 26.

Finally, I want to draw attention to the Hide Object logic Paul used for his “make link” icon and which I shamelessly borrowed for v2 of my demo as well…

…which neatly eliminates a TO that I had previously believed to be absolutely necessary and is responsible in part for the sleekness of the newly-streamlined graph.

I quote here from my portion of one of our email exchanges.

Your realization that this TO could be eliminated…

…turns out to be doubly brilliant. A. (obviously) it simplifies the graph, but something more subtle is also going on… B. it means that instead of (as per my original implementation) each row having to separately evaluate a stack of keys to decide whether to show/hide, that stack will only need to be evaluated once as it is the same for every child record (for a given parent).

E.g., given a scenario where doc 4 is linked to docs 1/2/3 and doc 8 is linked to docs 5/6/7, with the “hide” logic turned off for the “link” icon so I can display the key stack in a tool tip. My original logic gets evaluated on a per row basis, i.e., from the perspective of the “child” (parent record is irrelevant) — for the visible portal rows at any rate. Here are some examples…

…whereas your logic gets evaluated once per “parent” — in this case the parent is doc 8, and the stack only gets evaluated once and then is cached (or so I believe given that tool tip only displays once as I move my mouse vertically down the rows).