"FileMaker Black Box Scripts" is a made up phrase that refers to Scripts that, once compete, can be called in different ways, without having to touch them.
Here is one work in progress example ↴
Calling buttons 1/2
_Called Script 2/2
For those that like lively user group conversations, here is a before and after demo that goes into more detail...
DIGFM: Code Review, ♫ It's Getting Better All the Time ♬ (5/9/2024)
https://www.youtube.com/watch?v=oPZ_sJHVHVM&t=2280s
Other use cases?
I generally love the idea of black boxes. If we abstract and encapsulate our logic well enough to call it a "black box" then we're probably doing something right!
Every built in FileMaker script step/function is essentially a black box itself, with a friendly interface that we call, and we mostly don't worry about the "how" it does its job. I greatly appreciate when we strive for the same.
I've found that "black boxes" can be especially useful as parameterized wrappers around FileMaker script steps that don't expose the calc engine for each option.
E.g. The Print and Save as PDF steps have various options like "append", and "current record only/current found set", which you cannot toggle programatically. This is a case where I see some value in wrapping the steps so to control them via parameters. All those If/Else things can get complex, and you don't want to rewrite this in every script that needs that flexibility:
Another use case is to encapsulate the plumbing of Perform Find/Constrain/Extend Found Set.
You can write a wrapper that takes a json parameter, resembling the format of what you might pass to the Data API, and then execute the find for you. This is useful in cases where you might have, say, a reusable picker UI card, but you need to perform some different default filtering based on the situation. For example, say you have a Picker that lets you select a Product from a list and users can also search in a field to narrow the results. Maybe in some situations they can search "all products" and in others they can only search "products on this invoice". This dynamic find black box lets you store the filter criteria as JSON, and you can apply the filter as a constrain after a user types a new query in the picker search field.
This script also lets you do stuff like "saved/configurable finds", so different users can have their own "favorites".
Example param:
JSONSetElement ( "{}" ;
[ "finds[0].requests[0].fields[0].name" ; GetFieldName ( yourField ) ;JSONString ];
[ "finds[0].requests[0].fields[0].value" ; "Josh" ;JSONString ];
[ "finds[0].requests[0].omit" ; False ; JSONBoolean ];
[ "finds[0].type" ; "" ; JSONString ] // constrain, extend, find(default)
)
This idea is similar to the ProofGeist HTTP script, BUT DIFFERENT. That script tries to handle all types of requests and in doing so becomes a relatively shallow, unopinionated wrapper around cURL options. I think opinionatedness is what makes these types of black boxes most useful! Most web services have a documented set of error codes/conditions/responses, along with a mostly consistent authorization scheme. You can write a low-level HTTP script specifically for that integration that:
Once you've implemented this low level script, writing endpoint scripts is often just a couple lines of code wherin you pass the endpoint path and the endpoing-specific curl options needed, like the data your posting or a query string.
We use this pattern a lot:
Here's an example endpoint script. So short! BB: Projects: Delete ( projectId )
There are too many others to list and this post is already a novel!
I spoke to someone who did not like the name "FileMaker Black Box Scripts"
Is there a better name for Scripts that do NOT reference Fields (using Object Names instead)?
Tony, we just refer to them as ‘generic’. JSON parameters have transformed the way we can build context free scripts
Shadow Script
Sealed Unit describes an item which isn't meant to be opened in the normal course of events.
