FileMaker Scripts für verschiedene Aufgaben gleichzeitig nutzen

So erreichst Du mehr mit Deinen FileMaker Scripts


7. April 2021In Filemaker TippsBy Karsten Risseeuw7 Minutes

FileMaker Scripts dienen dazu, Abläufe zu standardisieren. Es ist die «Programmiersprache» von FileMaker, wenn man so will. Meist werden Aktionen durch Klick auf ein Button ausgelöst. Ein Script im Hintergrund erfüllt dann die Aufgabe. Arbeitsabläufe lassen sich so besonders einfach erstellen. Bei einer wachsenden Applikation wachsen auch die Anzahl Scripts, bis es unter Umständen Hunderte Scripts gibt. Schnell wird so etwas unübersichtlich. Dabei bestehen viele Scripts oft nur aus ein paar Zeilen. Kann man dies vereinfachen?

Ja, man kann Scripts vereinfachen. Folgende Vorgehensweisen haben sich bei mir bewährt:

  1. Scripts möglichst pro Layout erstellen
  2. Scripts möglichst pro Tabelle gruppieren
  3. Verschiedene kleinere Scripts in einem Script zusammenfassen.

Die Basisidee soll immer sein, kleinere Einheiten zu erstellen, die man gut prüfen kann, um diese dann für grössere Aufgaben zusammenzufassen.

Alle Scripts mit Wenn-Abfragen steuern

Als Faustregel wird bei mir jedes Script mit einem Scriptparameter aufgerufen. Ruft man ein Script ohne Scriptparameter auf, dann geschieht gar nichts. Die Funktionalität steht immer in einer Wenn-Abfrage. Das erhöht nicht nur die Sicherheit, sondern erlaubt auch die Verwendung des einen Scripts für mehrere Aufgaben.

Viele Scripts erledigen nur kleinere Aufgaben. Beispielsweise habe ich oft eine Seite mit Einstellungen, die ich anpassen kann. Diese Einstellungen kann ich sichern und wieder einlesen. Problemlos lassen sich beide Aufgaben (sichern/einlesen) in einem einzigen Script unterbringen. Beispielsweise so:

In diesem Screenshot ist eine vereinfachte Darstellung. Ganz oben steht der Name des Scripts. Dort kann man noch mehr Informationen ergänzen, wenn man will. Darunter gibt es eine Liste mit allen Script-Parametern, womit das Script aufgerufen werden kann. Das dient der Übersichtlichkeit und ist gleichzeitig so etwas wie ein Index zum Script. Die Script-Parameter zeigen die Abschnitte im Script. Erst danach folgt die eigentliche Funktionalität.

  1. Script-Name
  2. Liste mit Script Parametern, womit das Script aufgerufen werden kann
  3. Die eigentliche Funktionalität in Wenn-Abfragen.

Jeder Abschnitt erscheint dann mit einer Wenn-Abfrage. Möchte ich beispielsweise in einem Script das Lesen und Schreiben von Voreinstellungen erledigen, könnte das Script so aussehen:

Wenn [ Hole ( ScriptParameter ) = “schreiben” ]
*** HIER DIE LOGIK ***
Ende

Wenn [ Hole ( ScriptParameter ) = “lesen” ]
*** HIER DIE LOGIK ***
Ende

Damit erhalte ich ein Script, womit ich verschiedene Aufgaben lösen kann. Das reduziert die Anzahl Scripts. Ich habe Scripts, die oft bis zu einem Dutzend kleinere Aufgaben erledigen. Das ist keine Vorgabe, sondern eine Möglichkeit, sich die Arbeit zu erleichtern.

Teilaufgaben nutzen

Mit dieser Vorgehensweise lassen sich Teilaufgaben sauber trennen und trotzdem zusammenhalten. Statt ein Script mit vielen Unterscripts zu nutzen, können die Aufgaben vielleicht in einem Script zusammengefasst werden. Jede Wenn-Abfrage kann eine Teilaufgabe sein. Das hält die Scripts übersichtlich und man kann Teilaufgaben nacheinander oder einzeln abrufen.

Teilaufgaben können auf zwei Arten aktiviert werden:

  1. Man ruft aus dem Script dasselbe Script mit einem anderen Parameter auf
  2. Man ergänzt eine Wenn-Abfrage mit einem weiteren Parameter, der dann weiter unten im Script aufgegriffen wird.

Zur zweiten Variante hier eine Erklärung: Selbstverständlich sollen Script-Parameter beim ersten Aufruf des Scripts gesetzt werden. Das hält jedoch nicht davon ab, im Verlauf des Scripts immer den nächsten Schritt anzugeben – beispielsweise mit einer Variablen.

Wenn [ Hole ( ScriptParameter ) = “schreiben” ]
*** HIER DIE LOGIK ***
Variable setzen [ $NextStep ; Wert: “output” ]
Ende

Hier wird am Ende einer Wenn-Abfrage eine Variable gesetzt mit dem Stichwort “output”. Diese Variable soll auf den nächsten Schritt mit dem Namen “output” hinweisen. Insofern dieser Abschnitt in einer weiteren Wenn-Abfrage enthalten ist, sollte nach dem Abschluss des ersten Abschnitts, nun der zweite Abschnitt aktiviert werden. Das kann man beispielsweise so machen:

Wenn [ Hole ( ScriptParameter ) = “output”  oder  $NextStep = “output” ]
*** HIER DIE LOGIK ***
Ende

Die Ergänzung bei der Wenn-Abfrage ist nun so formuliert, dass man diesen Teil entweder mit einem ScriptParameter oder mit einer lokalen Variable aus dem Script ansteuern lässt. So lassen sich in einem Durchlauf mehrere Abschnitte «abarbeiten», ohne, dass man das Script mehrfach abrufen muss.

Machen diese Angaben einen Sinn? Das ist vielleicht nicht nur eine Frage des Programmierstils, sondern hängt ebenso mit der Art von Projekten zusammen, wofür man arbeitet. Bei mir steht immer die Frage voran: «Wie halte ich alles so einfach wie möglich?».

Warum sollte man dies anwenden?

Nachdem ich den Text hier oben auf Social Media gepostet hatte, wurde die Frage gestellt «Warum sollte man dies anwenden?». Ich wurde mir bewusst, dass ich noch nichts über die Gründe gesagt hatte, wieso ich zu dieser Strukturierung kam. Dazu nun hier ein paar Worte:

Zuerst einmal ist es einfach eine (von vielen) Methoden, Scripts zu schreiben. Es sind keine Vorgaben. Bei mir waren es verschiedene Erfahrungen, die zu dieser Methode geführt haben:

Herausforderungen

  1. In grösseren Datenbanken hatte ich Hunderte Scripts. Viele davon waren nur ein paar Zeilen gross.
  2. Öfters hatte ich dieselbe Funktion an mehreren Orten integriert oder ich hatte mehrere Scripts dafür im Einsatz.

«Je grösser» bedeutete nun auch «desto unübersichtlicher». Deswegen hatte ich folgende Anliegen:

Optimierungswünsche

  1. Reduziere die Anzahl Scripts
  2. Vermeide Redundanzen bei den Funktionen
  3. Erleichtere die Gesamtstruktur aller Scripts
  4. Optimiere die Möglichkeiten jedes einzelnen Scripts.

Die Ideen einer modularen Entwicklung von FileMaker Funktionen zeigten mir auf, wie das möglich ist. Insbesondere folgende Ansätze erwiesen sich als hilfreich:

Umsetzung

  1. Gruppiere Scripts möglichst nach Tabelle / Layout
  2. Reduziere Scripts idealerweise auf die «eigenen» Tabellen / Layouts
  3. Fasse mehrere Funktionen pro Tabelle / Layout in einem einzigen Script zusammen
  4. Jedes Script hat so mehrere «Teile», die durch einen ScriptParameter angesteuert werden können.

Soll dies jetzt eine rigide Regel sein? Nein. Es hat bei mir jedoch alle Scripts vereinfacht und die Anzahl Scripts drastisch reduziert. Als Methode hat sich das bei mir bewährt.